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Mapping  a  Domain  Model  and 
Architecture  to  a  Generic  Design 


Abstract:  In  contrast  to  the  number  of  reports  on  domain  analysis,  little  work 
has  been  done  in  describing  the  utilization  of  domain  analysis  results  in  the 
development  of  generic  designs  for  building  applications  in  a  domain.  This 
report  describes  a  process  for  mapping  domain  information  in  Feature- 
Oriented  Domain  Analysis  (FODA)  into  a  generic  design  for  a  domain.  The 
design  includes  supporting  code  components  that  conform  to  the  Object 
Connection  Architecture  (OCA),  a  model  for  structuring  software  systems.  A 
process  for  the  use  of  the  design  in  implementing  applications  is  included.  The 
processes  and  products  described  herein  augment  the  final  phase  of  domain 
analysis  (or  engineering)  described  in  the  original  FODA  report.  This  report 
also  documents  the  continuing  work  of  applying  FODA  to  the  movement  control 
domain.  The  design  and  Ada  code  examples  for  the  domain  used  in  the 
de_jment  are  from  pro.otype  software,  created  in  part  to  test  the  processes 
presented. 


1  Introduction  and  Background 

There  has  been  a  significant  amount  of  research  in  the  area  of  domain  analysis.  [Prieto-Diaz 
91]  provides  an  excellent  introduction  into  the  state  of  domain  analysis  as  a  software 
engineering  activity.  One  important  aspect  that  has  been  virtually  untouched  in  the  pertinent 
literature  is:  how  does  one  select  and/or  develop  a  design  for  use  in  building  applications  from 
the  products  of  domain  analysis?  Nearly  all  domain  analysis  methods  either  do  not  address 
this  issue  at  all  or  assume  there  is  a  design  to  be  (re)used  from  the  existing  system(s) 
analyzed.  There  is  no  notion  of  a  generic  design  that  reflects  the  allocation  of  capabilities  to 
subsystems  or  components  at  the  logical  level  that  is: 

•  independent  of  implementation  considerations  such  as  centralized  versus 
distributed  processing,  and 

•  usable  for  all  systems  to  be  built  and  maintained  within  a  program  family1 
from  the  domain. 

This  report  describes  our  efforts  in  this  area,  which  are  founded  upon  the  following  two 
premises: 

1 .  A  domain  model,  the  product  of  domain  analysis,  embodies  the  requirements 
for  software  in  a  domain.2 

1  The  term  "program  family"  is  used  as  defined  in  [Pamas  76). 

2  The  Feature-Oriented  Domain  Analysis  (FODA)  method,  developed  by  the  Software  Engineering  Institute 
(SEI),  is  one  domain  analysis  method.  It  captures  and  organizes  information  (especially  the  requirements)  from 
existing  systems  and  their  development  histories,  knowledge  captured  from  domain  experts,  underlying 
theory,  and  emerging  technology.  FOOA  emphasizes  the  understanding  of  the  commonalities  and  differences 
in  previous  and  anticipated  systems  In  that  domain.  The  pertinent  processes  and  products  of  FODA  are 
described  briefly  in  Section  2.2.  A  more  complete  description  of  FODA  is  given  in  [Kang  90). 
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2.  Software  architectures3  exist  that  provide  a  framework  for  generic  designs. 
Generic  designs  increase  the  reusability  of  software  components 
implemented  to  fit  within  that  design  by  creating  patterns  for  the  components. 

This  report  describes  a  process  for  mapping  domain  information  captured  in  FODA  models 
into  a  generic  design  for  software  in  a  domain.  The  Object  Connection  Architecture  (OCA)  is 
the  architectural  model  used  to  structure  the  generic  design.  The  use  of  the  OCA  in  structuring 
software  systems  is  described  briefly  in  Section  2.3  of  this  report  and  will  be  fully  documented 
in  a  subsequent  report. 

1.1  Audience 

This  report  is  intended  to  support  current  and  future  users  of  the  FODA  method  of  domain 
analysis  in  their  efforts  to  produce  reusable  software  assets  at  the  design  and  large  scale 
component  level.  Software  architects  and  designers  (such  as  the  Core  Asset  team  referred  to 
in  [Withey  94])  will  derive  the  most  benefit  from  the  report,  as  they  will  be  following  the  process 
and  creating  the  assets.  Domain  analysts  will  need  to  be  cognizant  of  the  process  described 
in  Chapters  4  and  5  to  understand  the  utilization  of  the  information  gathered  in  the  domain 
analysis  process. 

This  report  also  documents  the  SEI's  efforts  to  utilize  the  processes  and  procedures  described 
herein  for  the  development  of  prototype  software  for  the  Army  movement  control  domain  from 
FODA  models  documented  in  [Cohen  92]. 

This  report  is  one  of  four  reports  which  further  document  the  FODA  method  and  its  use.  These 
reports  are  products  of  the  SEI’s  continued  work  in  domain  analysis  and  its  application  within 
the  software  development  lifecycle.  The  other  three  reports  are: 

1.  Integrating  001  Tool  Support  into  the  Feature-Oriented  Domain  Analysis 
Methodology  [Krut  93], 

2.  A  Taxonomy  of  Coordination  Mechanisms  Used  in  Real-Time  Software 
Based  on  Domain  Analysis  [Fernandez  93],  and 

3.  Implementing  Model-Based  Software  Engineering  in  Your  Organization:  An 
Approach  to  Domain  Engineering  [Withey  94]. 

1.2  Purpose 

This  report  delineates  a  process  and  products  which  satisfy  the  intent  of  the  FODA 
Architectural  Modeling  process  and  migrates  the  use  of  FODA  products  into  the  design  and 
implementation  of  code.  This  migration  is  illustrated  in  Figure  1-1.  It  shows  that  the  mapping 
process  uses  domain  model  and  architecture  information  to  produce  a  generic  design  that,  in 
turn,  is  used  in  an  application  development  process  to  produce  application  code. 


1  Th«  tarni  software  architoctun  is  cfcfined  In  Section  2.3. 
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Figure  1*1 :  Roadmap  for  the  Mapping  Process 

Although  FOOA  products  are  assumed  to  be  the  inputs  to  the  processes  described  in  this 
reports,  usable  results  may  be  possible  through  use  of  the  products  of  other  domain  analysis 
methods.  The  alternative  method  used  must  capture  the  equivalent  information  contained  in 
FODA  Domain  Model  products  such  that  persons  attempting  to  follow  the  processes  can 
locate  and  use  the  specific  inputs  for  each  step.  The  resulting  software  structures  may  be 
implemented  in  many  popular  programming  languages,  such  as  Ada,  C,  C++,  and  PASCAL. 
The  Ada  programming  language  is  used  in  the  software  examples  described  in  this  document. 

This  report: 

•  demonstrates  the  concept  of  generic  designs  for  program  families, 

•  provides  practical  guidance  for  the  development  of  such  designs,  and  their 
use  in  building  software  systems,  and 

•  advances  the  state  of  the  practice  in  Domain  Engineering  and  software 
architectures. 

The  mapping  process  described  herein  is  intended  for  use  by  software  engineers  who  need 
to  develop  a  reusable  software  design  and  code  implementation  using  FODA  product  models 
as  the  basis  for  requirements  to  be  satisfied  by  software  systems  in  a  domain. 

1 .3  Overview  of  the  Movement  Control  Domain 

Before  going  into  the  mapping  process  in  any  detail,  it  is  appropriate  to  provide  a  brief 
overview  of  the  domain  from  which  the  examples  in  the  subsequent  chapters  and  appendices 
are  derived. 
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Movement  Control  is  the  planning,  routing,  scheduling,  control,  and  in-transit  visibility  of 
personnel,  units,  equipment,  and  supplies  moving  over  lines  of  communication  in  accordance 
with  the  directives  of  command  planning  [US Army  90].  The  most  common  application  within 
the  this  domain  used  by  the  majority  of  Army  units  is  Convoy  Planning.  The  operational 
features  needed  to  provide  convoy  planning  capabilities  include: 

•  Convoy  Building  -  selecting  the  vehicles  for  use  in  transporting  whatever  is 
to  be  moved  and  organizing  them  into  a  convoy. 

•  Routing  -  selecting  a  route  using  the  available  road  network  (and  potentially 
off-road  paths),  taking  into  account  the  capabilities  and  characteristics  of  the 
vehicles  involved. 

•  Scheduling  -  determining  the  travel  time  for  a  given  convoy  and  route 
combination,  accounting  for  additional  stops  as  required. 

Important  data  entities  for  these  features  within  convoy  planning  include: 

•  Units  -  encompassing  personnel,  equipment,  etc. 

•  Road  Network  •  a  structure  containing  information  about  points  of  interest 
and  the  roads  between  them. 

•  Schedules  -  a  structure  containing  information  about  events,  where  an  event 
is  a  combination  of  a  time  and  an  occurrence  of  interest. 

[Cohen  92]  provides  a  comprehensive  description  of  the  movement  control  domain  model. 
This  description  has  been  given  to  enable  the  reader’s  understanding  of  more  specific  issues 
in  the  movement  control  domain  used  as  examples  to  illustrate  important  concepts  in  the 
mapping  process. 

1 .4  Report  Overview  —  How  to  Read  This  Document 

The  remainder  of  this  report  is  organized  as  follows: 

Chapter  2  lays  the  foundation  for  the  mapping  process  by: 

1 .  describing  the  mapping  process  in  terms  of 

a.  the  application  of  various  classes  of  software  models,  and 

b.  how  other  software  engineering  processes  can  apply  the  different 
classes  of  models  in  obtaining  their  results. 

2.  giving  a  brief  description  of  the  Domain  Modeling  phase  of  FODA, 
concentrating  on  the  products  of  interest  derived  during  that  phase  and 
the  representation  of  those  products. 

3.  describing  the  OCA  in  terms  of  its  structures  and  concepts. 

Chapter  3  presents  the  mapping  process  in  terms  of  the  domain  model 
information  used,  the  products  generated,  and  the  applicability  of  the 
products  to  the  development  process. 
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Chapter  4  presents  the  Domain  Design  process  for  developing  specifications 
for  reusable  domain-specific  abstractions  from  information  captured  in  FODA 
models. 

Chapter  5  presents  the  Domain  Implementation  process  for  mapping  those 
specifications  onto  the  OCA  as  a  generic  design  with  supporting  code 
components. 

Chapter  6  describes  the  Application  Development  process  for  the  creation  of 
an  application  using  components  built  as  described  and  an  executive  built 
using  a  standardized  template. 

Chapter  7  presents  a  brief  set  of  conclusions  and  a  discussion  of  future 
directions  for  the  mapping  process. 

In  addition  to  the  material  in  the  main  body  of  the  report,  there  are  8  appendices  whose 
contents  are  described  below: 

1.  Appendix  A  presents  the  details  of  the  Domain  Design  process  via  the 
completion  of  prescribed  forms. 

2.  Appendix  B  presents  the  details  of  the  Domain  Implementation  process  via 
creating  code  units  that  satisfy  the  previous  specifications  through  the 
mapping  of  form  information  onto  various  code  constructs. 

3.  Appendix  C  presents  the  details  of  the  Application  Development  process  for 
the  use  of  the  generic  design  and  its  components  in  the  creation  of  an 
instance  that  satisfies  specific  requirements. 

4.  Appendix  D  lists  the  Specification  Forms  for  the  Subsystem,  Object  and 
Surrogate  abstractions  described  in  the  OCA. 

5.  Appendix  E  lists  the  code  templates  for  implementing  the  OCA  abstractions 
using  the  Ada  programming  language. 

6.  Appendix  F  discusses  some  of  the  implementation  issues  dealt  with  during 
the  trial  usage  of  these  processes,  focusing  on  Ada  language  interface 
issues,  and  the  idiosyncrasies  found  in  implementations  of  Ada  input/output 
packages.  It  also  provides  some  specific  examples  of  "C”  code  used  in  the 
user  interface  portion  of  the  movement  control  prototype  used  as  the  example 
case  in  the  report,  focused  mainly  on  the  description  of  several  reusable 
abstractions  for  X/Motif  input  and  output. 

7.  Appendix  G  provides  examples  of  completed  specification  forms  for  an 
example  subsystem,  object,  and  surrogate  from  the  Army  movement  control 
domain. 

8.  Appendix  H  provides  an  extensive  sample  of  code  from  the  Army  movement 
control  domain  as  empirical  evidence  of  the  viability  of  the  processes 
presented  in  this  report. 
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2  Context  for  the  Mapping  Process 


The  mapping  process  for  moving  from  domain  models  to  generic  designs  is  illustrated  in 
Figure  2-1 ,  in  SADT4  form.  The  major  input  is  the  domain  model,  with  its  collective  information 
about  the  capabilities,  data  organization,  and  processing  flow  for  systems  in  the  domain.  The 
architecture  is  a  control  input,  because  it  structures  the  output,  the  generic  design.  The  major 
resources  required  are  the  time  of  the  domain  engineers  to  perform  the  process  and  the  tools 
they  use  to  capture  the  results. 


Architecture 


Domain 

Model 


Mapping 

Process 


Generic  Design 


Domain 

Engineers, 

Tools 


Figure  2-1:  The  Mapping  Process  —  its  inputs  and  Outputs 

The  mapping  process  is  a  series  of  both  synthesis  and  analysis  steps,  which  is  broken  into  two 
major  groupings: 

1.  Analysis  of  the  domain  model  and  its  contents  to  find: 

a.  the  major  physical  or  logical  abstractions  that  maintain  state,  the 
domain  objects,  and 

b.  the  group  of  related  features  that  describe  the  subsystems  which 
utilize  the  objects  in  their  implementation. 

The  subsystems  and  objects  are  specified  using  forms  (described  in  the 
report)  to  collect  the  applicable  information  from  the  domain  model  structures. 

2.  Mapping  of  the  subsystem  and  object  specifications  onto  code  templates, 
using  the  information  collected  or  referenced  on  the  specification  forms  to 

_ complete  the  templates. 

*■  SMfMarca  88]  for  a  oompM*  wptancbon  of  ttwSADT  notation. 
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This  chapter  first  provides  the  reader  with  a  brief  explanation  of  me  basic  theory  for  software 
engineering  with  models  and  its  applicability  to  the  mapping  process.  Then  the  reader 
introduced  to  the  models  integral  to  the  mapping  process,  the  FODA  domain  model  and 
products  and  the  Object  Connection  Architecture. 

2.1  Using  Models  in  Software  Development 

Application  of  the  FODA  method  results  in  various  products,  most  of  which  are  expressed  in 
the  form  of  models.  Just  as  models  are  the  basis  for  describing  domain  information,  models 
should  be  the  basis  for  describing  software  designs  and  for  the  performance  of  software 
engineering  tasks  in  general.  A  software  model5  is: 

1.  A  view  of  a  domain  consisting  of  abstractions  important  for  analyzing  and 
implementing  a  capability  planned  for  a  software  system. 

2.  A  representation  of  a  system  that  focuses  on  a  single  concern,  usually  by 
simplifying  detail. 

There  are  various  kinds  of  models  that  can  be  defined  for  the  engineering  of  software: 

•  Abstract  model  -  A  set  of  concepts,  principles,  and  mles  used  to  prescribe 
the  structure,  allowable  content,  and  key  properties  of  a  concrete  model.  The 
set  is  constructed  with  the  expectation  that,  through  use  of  the  model, 
structure  and  behavior  can  be  added  to  create  concrete  models. 

The  notion  of  an  abstract  model  is  equivalent  to  that  of  an  abstract  class  in 
Objected  Oriented  Design,  such  as  described  in  [Booch  93].  An  abstract 
model  is  incomplete  when  initially  defined.  It  requires  the  insertion  of  domain 
information  to  be  fully  defined. 

Abstract  models  include  meta-level  concepts  that  are  independent  of  any 
domain.  Examples  include: 

•  the  notions  of  Aggregation/Decomposition,  Generalization/Specialization 
and  Parameterization,  used  as  the  guiding  principles  for  the  processes 
and  products  of  FODA.6 

•  the  use  of  consistent  form  and  the  various  ‘-ilities’  (understandability, 
modifiability,  etc.)  of  software  designs  and  code. 

•  Concrete  model  -  A  view  of  a  domain  that  organizes  domain  information  in 
elements  that  encapsulate  differences  among  existing  and/or  potential 
implementations  (members  of  the  program  family). 

•  Product  -  A  software  system  delivered  to  a  customer  which  contains 
instances  of  concrete  models. 


6 
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This  definition  of  product  is  not  meant  to  preclude  the  DoD  view  of  software 
deliverables,  which  includes  the  development  and  delivery  of  specification 
and  design  documentation  as  interim  products.  A  software  specification  can 
be  delivered  containing  an  instance  of  a  domain  model  and  a  design 
document  can  contain  an  instance  of  a  generic  design. 

A  SADT  diagram  showing  the  use  of  models  in  a  software  process  is  given  in  Figure  2-2.  It 
shows  that  a  model-based  software  process  is  the  result  of: 

•  using  previous  information  or  a  model  as  input 

•  applying  a  model  at  a  higher  conceptual  level  than  the  input  as  a  control,  and 

•  producing  as  output  a  model  at  the  same  conceptual  level  as  the  input. 


Input 


(e.g..  Domain 
Information) 


Control  Model 

(e.g.,  FODA  Modeling  Concepts) 


Software 

Engineering 

Process 

(e.g.,  FODA) 


Output 


(e.g.,  FODA  Domain  Model) 


Software 

Engineers 

(e.g.,  Domain  Analysts) 


Figure  2-2:  Use  of  Models  in  an  Engineering  Framework 

This  generalized  model-based  process  is  the  conceptual  basis  for  an  overall  software 
engineering  life  cycle  entitled  Model-Based  Software  Engineering  (MBSE),  a  concept  first 
described  by  the  SEI  in  [Feiler  93].  MBSE  enables  organizations  to  build  software  applications 
which  must  evolve  with  a  minimum  of  rework  and  scrap  to  meet  changes  in  mission  and 
technology.  MBSE  involves  building  models  of  the  requirements  and  design  for  a  family  of 
software  applications.  Application  generators  and  component  libraries  that  support  the 
software  models  are  also  built.  MBSE  is  a  focus  area  for  the  SEI’s  Engineering  Techniques 
Program  and  is  the  subject  of  a  recent  SEI  report  [Withey  94]. 
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The  usage  and  reification  of  models  from  abstractions  to  domain  specific  concrete  models  and 
on  into  delivered  software  products  is  the  fundamental  process  in  MBSE  and  occurs  in  many 
forms.  Concrete  models  are  created  from  the  application  of  abstract  models,  and  products  are 
derived  from  concrete  models.  As  an  example,  FODA  is  the  applic  :tion  of  domain  modeling 
concepts  (at  the  abstract  level)  to  information  on  existing  systems  and  new  technologies.  This 
process  is  shown  in  the  italicized  notations  on  the  named  flows  and  process  box  in  Figure  2-2. 

The  mapping  process  shown  in  Figure  2-1  supports  this  notion  of  model-based  software 
processes.  The  architecture,  used  as  the  control  input,  is  an  abstract  model  which  is  applied 
to  the  domain  model  to  produce  the  generic  design  output.  In  Chapter  3  of  this  report,  the 
mapping  process  will  be  refined  using  this  model-based  view. 

To  better  understand  the  mapping  process,  the  models  used  as  its  input,  control,  and  output 
(FODA  products,  the  OCA,  and  the  Generic  Design,  respectively)  are  described  in  the  next 
three  sections.  The  resources  (Domain  Engineers  and  tools)  are  not  further  described  in  this 
report. 


2.2  The  Domain  Model  —  FODA  Products  and  Representations 

The  FODA  method,  as  described  in  [Kang  90],  describes  three  major  products  created  during 
its  Domain  Modeling  phase.  They  are: 

1 .  The  Information  Model,7  which  captures  and  defines  the  domain  knowledge 
and  data  requirements  that  are  essential  in  implementing  applications  in  a  do¬ 
main. 

2.  The  Feature  Model,  which  captures  the  end  user’s  understanding  of  both  the 
general  and  specific  capabilities  of  applications  in  a  domain  and  describes: 

a.  the  context  of  domain  applications,  depicting  the  variability  of  the 
users  and  environment  for  applications  in  a  domain, 

b.  the  needed  operations  and  their  attributes,  and 

c.  representation  variations. 

3.  The  Operational  Model,6  which  identifies  the  functionality  and  behavior  (both 
commonalities  and  differences)  of  applications  in  a  domain.  It  provides  the 
foundation  upon  which  the  software  designer  understands  how  to  provide  the 
features  and  make  use  of  the  data  entities  in  the  previous  two  models 
described. 

[Krut  93]  documents  the  use  of  a  tool  to  capture  toe  products  of  the  FODA  domain  model.  The 
tool  is  “001"  from  Hamilton  Technologies,  Inc.,  documented  in  [001 SRM].  Since  this  tool  was 


7  EwSsriiportsimd  the  term  Entity  nshtkwhlp  Model,  but  snER  model  i»  only  one  format  tor  an  Information 
MexM.  A  Mmantic  data  modal  of  object  moM  urn  altwnativ*  formats. 


*■  E»*wi»porWu«edtlwt*rm  Functional  Modsl 
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used  to  represent  two  ot  the  three  domain  models,  the  pertinent  001  notation  will  be  briefly 
explained  in  the  following  paragraph  and  examples  of  its  use  wilt  be  shown. 

The  basis  of  FOOA  Information  Modeling  is  composed  of  two  basic  relationships:  the  is-a  and 
conslsts-of.9  The  is-a  relationship  is  further  refined  by  adding  a  third  relationship,  the  Is-set- 
of.  Using  these  relationships,  the  entities  used  to  describe  the  information  content  of  a  domain 
are  described  and  organized.  Such  an  organization  can  be  shown  using  the  001  notation  as 
described  below. 


Ofttor^tuptooM) 


tesk_forc«(tupteof:4) 
Intelligence tupi*of:2) 

IPB(tupt*of:3) 
technical JnMliganca(tuptoof:1 ) 


aupportpupteohs 


I'Mskinated  mi  it— fti 

Tv" 

route(oaatof)  I  \ 

/  W( 

Lcteai 

networks) 


tranapoctetlon_intelliganca(tupteof:3) 
W(*tr) 

control_claaaification(onaof  :S) ) 


auppliaa(tiiplaof:S)s^aafvicaa(atr) 

to*asaats(tupteof:3)  auppiy_pointe<oaalof) 


aquipmant(str)  \  natworks(osatof) 
unit_h>cationa(osatof)  teciHtlaa(alr) 


natwork_sagmanta(daf)ne<tes:  rosdlnformstion) 


Figure  2-3:  Example  of  an  001  Information  Model 

The  001  TMap  (or  TypeMap)  provides  a  tree-like  structure  with  each  node  corresponding  to 
an  object  type.  Figure  2-3,  shown  above,  depicts  an  abbreviated  version  of  the  Information 
Model  for  the  movement  control  domain.  The  TMap  enables  the  modeling  of  the 
decomposition  of  objects  using  sets,  arrays,  trees,  classification,  reference,  extension,  and 
primitive  types.  These,  in  turn,  map  readily  to  the  constructs  and  semantic  notions  of  many 
programming  languages.  The  concepts  of  generalization,  aggregation,  and  attributes  were 
transformed  using  the  TupieOf,  OSetOf,  and  OneOf  abstract  types  within  the  001  TMap  syntax 
as  follows: 

•  The  decomposition  of  a  parent  object  into  different  component  parts  (children 
types)  was  represented  by  the  TupieOf  abstract  type,  representing  the 
semantics  of  the  record  construct.  These  component  parts  may  be  objects  of 
the  same  type  or  objects  of  different  types. 

*  Sm  Section  52  of  (Kang  90]  for  •  mors  dstaHsd  description  of  the  usage  of  these  constructs  In  FOOA. 


•  The  one-to-many,  parent-child  relationship  was  represented  with  the  OSetOf 
abstract  type.  The  OSetOf  abstract  type  represents  an  ordered  set  of  objects, 
containing  zero  or  more  objects  of  the  same  type.  The  OSetOf  type  can  be 
implemented  in  any  number  of  ways;  lists  and  arrays  are  two  examples. 

•  There  exist  entities  (or  objects)  in  which  there  are  many  possible  children 
types  yet,  when  an  object  instance  is  created,  exactly  one  of  the  child  types 
exists.  These  are  represented  by  the  OneOf  abstract  type.  Languages  that 
support  variant  structures  readily  implement  these  semantics. 

To  use  an  001  model,  the  user  (or  tool  using  the  internal  representation)  traverses  the  tree  and 
uses  the  semantics  corresponding  to  the  001  type  at  each  node  to  understand  the  model  and 
its  contents.  For  example,  the  movement  control  environment,  shown  at  the  top  of  Figure  2-3, 
consists  of  six  data  aggregates,  as  represented  by  the  TupleOf  notation.  One  of  these,  the 
distribution  jpians  entity,  consists  of  two  items.  The  TCP  (the  T raffic  Control  Plan)  is  shown  as 
an  OSetOF  of  designated_routes,  describing  the  notion  of  a  collection  or  subset  of  the 
available  roads  which  will  be  placed  under  specific  control  to  regulate  their  usage.  Under  the 
transportation  subtree  and  its  methods  branch,  the  four  entities  shown  with  the  boolean 
options  describe  the  notion  used  to  the  optional  incorporation  of  road,  water,  rail,  and  air  as 
transport  mechanisms. 

The  001  notation  fully  represents  the  semantic  model  concept  of  the  FODA  Information  Model. 
The  semantic  model  captures  the  bulk  of  the  data  requirements  for  the  domain. 


fnovama«it(tiiplaof:4) 


convoy  _bulklii>a<tupt*of:2) 


d*fenM_ptenning(boolMn) 
cofejmn_foanation(tuplaof:4) 

/ /  •nt*f_gro«ipfeiga(bootMn)  /  \ 

/ n)  //  /  I  \pdm*nr~ 


highway  _raaulation(tupi«of:2) 

hwy_trafflc_rag(boolMn) 
daconflictk>n(tupi*of:3) 


dapandant_avanta(boolaan) 

/  fn<tep«ndinL«vOTts(t>oolMn) 
pmlM_«v«nts(boolMn) 

achaduMng(tuplao<:4) 


coiumnlangth(onaof;2) 

/routlng_opa(tuplaof:3)  I  aaLactual_tlma(boolaan) 

/V  t  /  a mMm!  **— — t — > 

•4actk>n<onaof2)  /  \\  / tMarmlrw_control _pont>(booiaan) 

f\  \  \  catcuia>a_travai_ttma(booiaan) 

/>7rT\ 

z'  \  antar_aagmant(boolaan) 


■nMimf 

Figure  2-4:  Example  BepreeentaMon  of  an  001  Features  Model 
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The  001  TMap  notation  is  also  used  to  represent  the  features  model.  Figure  2-4  on  the 
following  page  depicts  a  portion  of  the  movement  control  features  model,  focusing  on  the 
features  relevant  to  convoy  planning.  The  features  were  identified  and  structured  as  optional, 
alternative,  or  mandatory  as  described  in  the  FODA  method,  in  the  following  ways: 

•  the  optional  features  are  modeled  as  leaf-node  objects  of  type  Boolean;  this 
allows  their  later  designation  of  their  usage  with  True  or  False  selection, 

•  the  alternative  features  are  modeled  as  a  OneOf  abstract  type,  which  readily 
captures  the  notion  of  alternative, 

•  and  mandatory  features  as  a  TupleOf  abstract  type. 

Since  a  TMap  follows  the  same  tree-like  structure  as  the  baseline  features  diagram,  the 
concept  of  “reachability”  defined  in  the  FODA  report  is  maintained  within  a  TMap. 

The  Operational  Model  is  captured  using  any  number  of  CASE  tools  which  allow  for  the 
integrated  definition  of  the  functional  and  behavioral  characteristics  of  applications  software  in 
a  domain.  The  SEI  reports  cited  previously  describe  the  use  of  various  tools  to  support  this 
model. 

Now  that  the  pertinent  FODA  products  have  been  described,  it  is  time  to  discuss  the 
architectural  concepts  needed  to  produce  a  generic  design.  The  concepts  are  embodied  in  the 
OCA,  which  is  the  subject  of  the  next  section. 

2.3  The  Architecture  —  The  OCA 

In  [Shaw  90],  the  term  software  architecture  is  defined  as:  a  software  design  at  a  level  of 
abstraction  that  focuses  on  the  patterns  of  systems  organization  that  describes  how 
functionality  is  partitioned  and  how  those  elements  are  interconnected.  There  are  two  key 
parts  to  an  overall  organizational  pattern,  a  partitioning  strategy  and  a  coordination  model. 

A  partitioning  strategy  is  the  criteria  used  to  decompose  large  software  problems  into 
smaller  subproblems  and  the  allocation  of  those  subproblems  to  software  components  that  will 
solve  them.10  In  the  OCA,  the  partitioning  strategy  is  realized  by  building  blocks  such  as 
subsystem  and  surrogate  structures  and  their  components,  and  the  executive.  The 
coordination  model  is  trie  glue  that  binds  separate  activities  into  an  ensemble  [Gelemter  92]. 
In  the  OCA,  the  coordination  model  is  realized  in  rules  and  templates  that  determine  how  the 
building  blocks  interact  with  one  another. 

A  key  attribute  of  a  good  architecture  is  the  separation  of  the  coordination  strategy  or  model 
(the  flow  of  control  through  the  software,  or  mission)  from  the  providers  of  operations  or 
services  (the  building  blocks  or  components).  This  separation: 

•  allows  a  change  in  operation,  or  service  provided  (potentially  due  to  a  new 
piece  of  equipment  or  information),  without  requiring  a  change  in  the  existing 
mission  software,  and 

10-  Sn  [Abowd  93]  and  [USAF  93]. 
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•  allows  a  change  in  the  mission  without  necessarily  requiring  a  change  in  the 
service  providers  carrying  out  that  mission. 

Because  of  the  dear  separation  between  the  partitioning  strategy  and  coordination  model, 
program  families  can  be  designed  using  the  OCA  that  are  highly  modifiable  with  respect  to 
broad  classes  of  change.  The  next  section  presents  an  overview  of  the  OCA,  focusing  on  the 
partitioning  strategy  and  coordination  model  embodied  within  it. 

2.3.1  Overview  of  the  OCA 

The  OCA1 1  is  an  abstract  model  that  provides  an  architectural  pattern  for  the  packaging  of 
software.  The  architectural  pattern  embodied  in  the  OCA  allows  software  developers  and 
reusers  to  distinguish  the  design  and  packaging  of  the  service  providers  and  the  code 
elements  that  are  mission  oriented.  The  three  architectural  elements  are  called: 

1 .  objects  (sen/ice  providing  elements) 

2.  controllers  (elements  that  embody  a  mission  through  use  of  objects) 

3.  executives  (mission  activator  elements) 

The  architectural  elements  of  the  OCA  and  the  components  used  to  implement  the  elements 
are  described  further  in  the  following  paragraphs. 

2.3.2  OCA  Components 

A  controller  and  its  associated  objects  are  called  a  subsystem,  a  single  product  or  family  of 
products  whose  definition  is  wholly  self-contained.  The  subsystem  model  is  an  essential 
element  to  understanding  the  OCA  and  is  illustrated  in  Figure  2-5.  The  components  of  the 
subsystem  model,  Objects,  ControiKs,  Imports,  Exports,  and  Signatures,  are  described  in  the 
order  given.  Then  a  variant  of  the  subsystem,  the  surrogate,  is  described.  Finally,  the  role  of 
the  executive  is  discussed. 

2.3.2.1  Objects 

An  object  maintains  state  information  about  the  behavior  of  a  real-world  or  virtual  entity.  The 
kinds  of  real-world  objects  that  can  be  modeled  are  things  like  engine  parts,  i.e.,  cams,  pistons, 
rings,  and  lifters.  On  the  other  hand,  an  object  can  model  a  thing  that  is  not  physically 
realizable,  such  as  a  map  that  depicts  the  roads  in  an  area.  An  object,  when  implemented, 
performs  two  important  functions: 

1 .  it  provides  services  through  internal  subprograms,  and 

2.  it  maintains  a  readable  state. 


The  OCA  is  based  upon  the  Object  Connection  Update  (OCU)  paradigm  developed  by  the  Ada  Simulation 
Validation  Project  (a  funded  SEI  project  from  1 967  to  1 969)  sponsored  by  the  U.S.  Air  Force  Aviation  Systems 
Command  (ASC/YT)  and  described  in  [Lea  88].  Parts  of  this  paractgm  have  been  incorporated  into  the 
Structural  Modeling  process  and  framework  desorbed  in  [Abowd  93]  and  [USAF  93]. 
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The  implementation  of  an  object  is  abstracted  through  a  manager.  An  object  manager 
maintains  a  consistent  procedural  interface  to  the  underlying  representation  of  an  object  vie 
recurring  patterns  for 

•  the  procedure  names  for  its  operations,  and 

•  its  usage  of  data  passed  as  parameters. 

Thus,  no  matter  how  the  object  changes  the  implementation  of  its  operations  or  its  internal 
representation,  the  operation  names  and  their  data  inputs  and  outputs  available  through  the 
manager  should  not  change  for  a  well-defined  object. 


2.3.2.2  Controllers 

As  an  engine  is  an  aggregate  of  its  parts  (the  cams,  pistons,  rings  and  lifters),  a  controller 
aggregates  objects  to  form  a  cohesive  subsystem.  A  controller  is  the  locus  of  information 
pertaining  to  the  subsystem’s  mission,  i.e.,  the  specific  activity  or  task  with  which  the  group  of 
objects  is  charged  (an  engine  provides  rotational  torque  and  power  to  the  remaining  drive  train 
subsystems).  A  mission  is  a  bounded  activity  within  a  single  domain  of  expertise.  The  mission 
of  a  subsystem  is  captured  in: 


1st  in  the  figure,  the  line  apMUng  the  ControNer,  Object,  and  Import  component*  to  used  to  depict  the  separation  of 
concerns  between  the  specification  of  the  callable  interface  and  the  implementation  for  each  component 
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•  what  objects  are  needed  to  perform  a  cohesive  set  of  related  operations  at  a 
level  of  abstraction  above  individual  requirements  (or  low  level  features), 

•  where  information  inputs  and  outputs  are  located,  and 

•  when  low-level  operations  are  invoked  and  in  what  order. 

The  controller  is  used  to  drive  the  subsystem,  including  the  management  of  interactions 
between  the  objects  within  the  subsystem  and  the  usage  of  data  elements  via  use  of  a  set  of 
explicit  constructs  for  data  transfer,  the  important  export  structures.  These  two  structures  are 
described  in  the  following  two  sections. 

2.3.2.3  Imports 
The  import  structure: 

•  is  the  locus  of  other  subsystem  state  data  needed  by  a  subsystem  to  achieve 
its  mission. 

•  collects  state  data  from  other  subsystems’  export  areas  needed  to  achieve  a 
subsystem's  mission. 

•  maintains  separation  of  concerns  between  subsystems  and  their  objects. 

The  import  structure  defines  the  interface  for  data  input  from  the  other  subsystems.  The 
controller  accesses  input  data  needed  for  object  operations  via  this  structure,  thus  the  control 
flow  from  the  controller  to  the  import  structure  and  the  return  data  flow  illustrated  in  Figure  2-5. 

2.3.2.4  Exports 
The  export  structure: 


•  is  the  locus  of  a  subsystem’s  state  data  needed  by  other  subsystems  to 
achieve  their  missions. 

•  provides  storage  area  for  a  subsystem  for  data  reflecting  the  state  of  the 
subsystem's  mission. 

•  allows  access  to  required  state  data  without  requiring  access  to  the  object. 

The  export  structure  defines  the  data  output  interface  for  use  by  the  other  subsystems.  The 
controller  places  the  required  results  of  invoked  operations  into  this  structure,  as  indicated  by 
the  control  and  data  flows  from  the  controller  to  the  export  structure  shown  in  Figure  2-5. 


2.3.2.5  Signatures 


Signatures  are  a  powerful  mechanism  for  abstraction  in  the  OCA;  they  are  a  formal 
representation  of  the  interface  to  components  (objects,  subsystems,  and  surrogates)  that 
provide  services.13  Signatures  play  a  major  role  in  how  the  high  degree  of  separation  of  control 
and  data  flow  seen  in  the  OCA  is  achievable  in  practice. 


[Srinivaa  91]  describes  the  concept  of  signatures  as  a  means  of  describing  the  key  notions  of  domain  entities 
as  names  and  how  the  names  form  a  vocabulary  for  describing  a  domain.  Signatures  were  cited  as  the  most 
fundamental  of  the  three  ingredients  in  the  specification  of  a  domain,  as  they  are  used  within  the  axioms 
(formulas)  and  models  in  an  algebraic  specification.  Signatures  are  also  described  as  a  useful  notion  when 
attempting  to  identify  a  component's  reuse  potential  in  [Zaremski  93], 
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For  objects,  Signatures  consist  of  information  about  the  details  of  the  functionality,  in  particular 
the  processing  options,  provided  by  the  object’s  operations.  Object  signatures  contain  abstract 
names  for  the  services  (and  their  underlying  algorithms)  provided  by  the  objects,  and  hide  the 
mapping  of  the  abstract  service  (and  the  selected  name)  to  the  implementation  of  the  service. 
In  this  way,  implementations  may  change  and  alternative  algorithms  may  be  selected  by 
various  users  with  minimal  effort  because  users  access  the  services  through  the  logical  names 
provided  by  the  signatures  rather  than  directly. 

For  subsystems,  the  Signatures  include: 

•  Object  Signatures  information  that  must  be  visible  to  other  subsystems, 
surrogates,  and  the  executive, 

•  the  names  of  all  of  the  data  items  accessible  individually  and  by  aggregate 
via  the  subsystem  controller  operations, 

•  names  for  the  internal  state  of  the  subsystem,  used  by  the  executive,  to 
control  overall  system  flow. 

The  signatures  for  surrogates  are  equivalent  in  content  to  those  for  subsystems. 

Subsystem  signatures  allow  the  use  of  a  subsystem’s  operations  without  explicit  reference  to 
(or  knowledge  of)  the  underlying  objects  comprising  it,  the  specific  features  they  provide,  or 
even  the  names  that  have  been  chosen  to  represent  the  services  at  the  object  level.  A 
signature  for  a  subsystem  may  provide  varying  degrees  of  abstraction;  the  most  trivial  (and 
least  abstract)  subsystem  signature  contains  the  union  of  the  signatures  of  each  object  in  the 
subsystem.  More  sophisticated  subsystem  signatures  provide  higher-level  services  by 
mapping  simple  names  onto: 

•  services  provided  by  objects, 

•  specific  instantiation  of  services  provided  by  objects,  such  as  an  invocation 
of  an  object’s  services  with  a  specific  set  of  parameters,  or 

•  complex  sequences  of  the  object-provided  services. 

For  example,  an  object  might  encapsulate  a  database  that  represents  a  terrain  map  of  a 
particular  area.  Its  signature  might  include  facilities  for  returning  the  height  above  sea  level  at 
a  given  location,  each  facility  with  different  accuracy  and  computational  characteristics.  This 
signature  would  remain  stable  even  if  the  database  were  replaced  with  one  of  less  resolution 
that  might  require  the  object  to  extrapolate  among  the  heights  or  nearby  coordinate  locations. 

Additionally,  this  database  object  might  be  part  of  a  subsystem  that  computes  the  as-travelled 
distance  between  two  points.  The  signature  for  the  subsystem  might  represent  a  service  that 
returns  the  distance,  given  the  starting  point  and  destination.  This  signature  may,  unknown  to 
those  outside  the  subsystem,  map  to  a  series  of  object  operations,  such  as  deriving  a  point- 
to-point  routing  along  roads  between  the  given  points  or  calculating  distances. 


Signatures  provide  a  conceptual  link  from  the  executive  to  lower  levels  of  functionality  that  is 
independent  of  the  implementation  of  that  functionality.  Figure  2-6  illustrates  this  linkage.  The 
dependency  links  depict  the  incorporation  or  usage  of  a  Signatures  structure  by  another 
structure  and  are  shown  by  the  solid  arrows.  The  dashed  arrows  in  the  opposite  direction 
reflect  the  visibility  of  the  Signatures  names  to  the  structure  using  them.  With  the  transitive 
inheritance  of  the  Object  Signatures  (via  the  Subsystem  Signatures)  into  the  executive,  the 
executive  now  has  sufficient  visibility  to  invoke  object  operations  in  the  desired  manner,  thus 
the  conceptual  link  between  them.  Only  those  parts  of  the  Object  Signatures  needed  by  the 
executive  are  required  to  be  passed  along  by  the  Subsystem  Signatures.  These  are  the  names 
of  those  low-level  processing  options  that  must  be  visible  to  the  executive  (for  any  number  of 
reasons).  The  names  provide  a  sufficient  description  to  express  the  semantics  of  the  option 
without  violating  the  coordination  model,  where  rules  explicitly  prohibit  invocation  of  object 
operations  from  within  the  executive  directly. 


Figure  2-6:  Signatures  as  Conceptual  Links  to  Object  Functionality 

Sections  5.3  and  5.5  describe  specific  examples  of  the  uses  of  signatures  for  objects  and 
subsystems,  respectively. 

2.3.2.B  Surrogates 

An  important  variation  of  the  subsystem,  the  surrogate,  is  used  to  aggregate  information  about 
physical  or  logical  devices  with  which  the  application  is  to  interface.  These  devices  include: 

•  file  systems  or  databases, 

•  other  computers  via  hardware  devices  and  software  protocols,  and 

•  human  users  via  devices  ranging  from  dumb  terminals  and  keyboards 
through  bitmapped  displays  with  pointing  devices  and  sophisticated 
graphical  support  packages. 
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The  word  surrogate  is  defined  in  [AHD  85]  as:  one  that  takes  the  place  of  another,  substitute. 
The  most  important  goal  of  the  surrogate  structure  is  to  provide  a  sufficiently  abstract  notion 
of  the  logical  device  as  to  allow  for  the  substitution  of  different  physical  devices  or 
implementations  (i.e.,  different  operating  systems  and  file  structures).  If  a  device  is  sufficiently 
well  abstracted,  then  exploiting  its  capabilities  in  applications  is  only  a  matter  of: 

•  characterizing  the  physical  attributes  of  the  actual  device  to  be  used  in  a 
specific  application,  and 

•  characterizing  the  data  to  be  handled  by  the  surrogate  for  the  application. 

The  key  differences  between  subsystems  and  surrogates  lie  in  two  major  areas: 

1 .  Surrogates  are  intended  to  be  domain  or  product  line  independent,  at  least  to 
the  level  of  the  format  of  the  data  types  provided  within  the  application.  This 
domain/product  independence  also  extends  to  the  consistency  of  the  names 
for  its  operations,  versus  the  domain  specific  operation  names  used  within 
subsystems.  The  notion  of  names  for  subsystem  and  surrogate  operations  is 
discussed  further  in  Sections  5.4  and  5.6. 

2.  A  surrogate  structure  may  be  incomplete.  For  example,  an  input-only  device 
will  not  import  any  data  and  an  output-only  device  will  not  export  any  data  to 
be  used  by  other  subsystems.  It  is  expected  that  all  subsystems  will  require 
both  an  import  and  export  structure  to  be  fully  specified. 

The  overall  structure  of  surrogates  is  equivalent  to  that  for  subsystems.  They  contain 
controllers,  imports,  exports,  and  a  signatures  structure  at  the  controller  level.  The  objects 
underlying  surrogates,  the  handlers  and  transforms,  are  structures  that  provide  the  necessary 
interfaces  to  the  device(s)  and  the  functionality  to  implement  data  exchanges  between  the 
application  and  the  device(s).  The  internal  structuring  of  surrogates  into  handlers  and 
transforms  is  discussed  further  in  Section  5.8. 

2.3.2.7  Executives 

The  executive  provides  the  operating  environment  for  the  subsystems  within  the  application 
and,  in  most  cases,  is  the  arbitrator  over  conflicts  between  processes  competing  for  time  and 
access  to  shared  resources.  The  executive  monitors  and  controls  time  for  subsystems  and 
monitors  interfaces  to  external  entities  such  as  hardware  devices,  other  computers,  and 
humans,  i.e.,  application  users  through  the  surrogates.  The  role  of  the  executive  in  the  overall 
flow  of  control  in  the  OCA  is  clearly  described  in  the  next  section. 

2.3.3  Flow  of  Control  and  Data  in  the  OCA 

When  the  OCA  is  used  consistently  as  the  basis  for  implementing  the  operational  aspects  of 
a  domain’s  features,  the  resulting  subsystems  and  surrogates  can  be  readily  combined  into 
complete  applications  with  an  executive.  The  executive  provides  the  appropriate  level  of 
control  over  the  application  via  the  subsystem  controllers.  Yet,  because  of  the  use  of  the 
Signatures  structure,  the  executive  has  no  visibility  to  the  data  needed  in  the  application,  thus 
achieving  an  important  separation  of  concerns  in  the  resulting  software.  The  flow  of  data  and 
control  is  illustrated  in  Figure  2-7. 
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The  solid  arrows  show  the  flow  of  control  within  the  system.  Except  for  the  handling  of  error 
conditions  and  the  surrogates  providing  feedback,  control  always  flows  downward. 
Subsystems  do  not  make  calls  to  other  subsystems  or  their  objects.  Calls  to  objects  are  made 
only  by  the  appropriate  subsystem  controller.  This  standardizes  the  control  flow  which 
increases  the  understandability  and  maintainability  of  the  software.  The  objects  and 
subsystems  also  have  mechanisms  for  error  handling  and  recovery  which  will  be  discussed  in 
detail  in  a  subsequent  report. 

The  dashed  arrows  indicate  the  flow  of  data  between  the  subsystems.  Data  placed  in  a 
subsystem's  export  structure  is  available  for  use  by  other  subsystems  via  their  respective 
import  structures.  Export  structures  have  no  knowledge  of  where  their  exported  data  are  used. 
It  is  the  responsibility  of  the  import  structure,  when  implemented,  to  know  where  to  get  the  data 
necessary  to  provide  aH  required  inputs  for  the  subsystem's  operations. 
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Figure  2-7:  Overall  Flow  of  Data  and  Control  in  the  OCA 

In  summary,  the  OCA  is  an  architecture  that  allows  one  to  specify  a  generic  design  for 
software  systems  using  objects  managed  by  controllers  under  the  direct  supervision  of  an 
executive  where: 

•  objects  model  the  behavior  of  real-world  (or  virtual)  components  and 
maintain  state. 

•  controllers  aggregate  objects  and  manage  connections  between  them  based 
upon  a  reaction  strategy. 

•  executives  manage  the  subsystem  and  surrogate  controllers,  time,  and  the 
application  state  to  provide  acceptable  response  to  stimuli. 

A  discussion  of  some  of  the  benefits  the  OCA  provides  in  application  development  and 
maintenance  is  given  in  Section  3.4. 


CMU/SB-94-me 


20 


2.4  The  Generic  Design 

The  resulting  output  of  performing  the  mapping  process  is  the  generic  design.  This  design  may 
take  many  forms,  depending  upon  the  architecture  used  as  a  control.  The  important  concept 
is  that  the  generic  design  is  a  domain  dependent  instance  of  the  selected  architecture.  It 
should  always  to  possible  to  recognize  a  generic  design  as  an  instance  of  architecture  X,  if 
that  architecture  has  a  well-understood  partitioning  strategy  and  coordination  model  as 
described  in  Section  2.3. 

For  example,  Figure  2-8  depicts  the  top-level  structure  for  the  convoy  planner  prototype 
application  developed  by  the  authors  during  the  initial  execution  of  the  mapping  process.  The 
use  of  the  OCA  is  readily  apparent  in  the  designation  of  subsystems  and  surrogates,  and  in 
the  uniform  flow  of  control  between  them  and  the  executive.  Appendices  G  and  H  further 
reflect  the  use  of  the  OCA,  as  they  capture  instances  of  use  of  the  specifications  forms  and 
templates  as  represented  in  Appendices  D  and  E,  respectively. 


Figure  2-8:  Convoy  Planner  Generic  Design 
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In  describing  the  usage  of  models  in  software  engineering  and  the  role  of  the  domain  model 
architecture  and  generic  design,  the  context  for  understanding  the  mapping  process  is 
complete.  The  next  chapter  provides  an  overview  of  the  mapping  process,  including  its 
applicability  and  limitations. 


3  Overview  of  the  Mapping  Process 


Previously,  the  mapping  process  has  been  described  using  a  SADT  view  of  a  process  with 
input  and  output  products  as  various  kinds  of  models.14  Now  that  the  models  pertinent  to  the 
mapping  process  have  been  described,  that  view  can  be  refined  to  focus  on  the  use  of  those 
models  within  processes  that  together  describe  the  entire  mapping  process. 

3.1  Partitioning  the  Process 

The  mapping  process  has  steps  that  apply  to  both  the  Domain  Engineering  and  Application 
Engineering  processes  as  described  in  [Withey  94].  Figure  3-1  shows  an  expanded  view  of 
the  mapping  process  with  three  subprocesses  illustrated: 

1.  Domain  Design,  which  takes  a  Domain  Model  as  input  and  applies  a  Parti¬ 
tioning  Strategy  from  an  Architecture  as  a  control  model  to  produce  a  Generic 
Design. 

2.  Domain  Implementation,  which  takes  a  Generic  Design  as  input  and  applies 
Code  Templates  and  Design  Rules  from  an  Architecture  as  a  control  model 
to  produce  the  Supporting  Components  (for  the  Generic  Design). 


3.  Application  Development  which  takes  a  set  of  Components  and  a  System 
Specification  as  input  and  applies  Rules  and  Code  Templates  to  produce  the 
Application  Code. 


Sm  Figure  2-1  on  peg*  7  and  Figure  2-2  on  page  9. 


CMUiSEMM-TR-e 


23 


The  Domain  Design  and  Domain  Implementation  processes  together  form  the  mapping 
process  which  is  the  primary  focus  of  this  paper.  However,  these  processes  do  not  present  a 
complete  picture  in  that  there  is  no  process  pertaining  to  the  use  of  the  resulting  concrete 
models  (the  design  and  components)  in  the  development  of  application  products.  The 
Application  Development  process  is  intended  to  complete  the  process  of  migrating  domain 
knowledge  into  delivered  products  in  a  systematic  manner. 

Chapters  4  through  6  define  a  series  of  steps,  segmented  into  three  processes  as  summarized 
above.  The  goat  of  the  Domain  Design  process  is  to  coiled  the  information  needed  to  develop 
the  package  structures  that  implement  the  OCA.  This  information  is  collected  onto  a  set  of 
forms  (shown  in  Appendix  D)  that  will  be  the  major  inputs  for  the  Domain  Implementation 
process.  In  Domain  Implementation,  a  set  of  code  units  (Ada  package  templates  are  shown  in 
Appendix  E)  which  implement  each  subsystem,  object,  or  surrogate  defined  during  the 
Domain  Design  process.  Chapters  4  and  5  describes  these  two  processes. 

The  Application  Development  process  takes  the  user  through  some  portions  of  the  process  of 
using  the  completed  or  partial  components  to  develop  an  application  within  the  domain. 
Chapter  6  describes  this  process. 
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Figure  3-2:  Migration  of  Domain  Data  to  Specifications  and  Code 

Figure  3-2  Mustrates  the  overall  flow  of  the  mapping  process,  showing  the  transitions  from  the 
domain  model  to  code  via  the  use  of  the  specification  forms.  Note  how,  during  the  Domain 
Desist  process,  the  specification  forms  gather  information  from  diverse  sources  via  the 
multipie  models  that  coNectivofy  denote  the  domain  and  then  how  that  information  is 
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repartitioned  into  multiple  code  units  during  the  Domain  Implementation  process.  This  is 
similar  to  how  requirements  documents  are  written  for  systems,  gathering  information  from 
diverse  sources  into  a  single  document  (or  set  of  documents),  and  how  those  documents  are 
used.  This  similarity  and  others  within  this  development  process  are  the  focus  of  the  next 
section. 


3.2  Viewing  the  Process  as  a  Normal  S/W  Development  Process 

The  mapping  process  is  analogous  to  the  generic  software  development  process  of  producing. 
1)  a  specification,  then  2),  a  design  that  meets  the  specification,  and  finally  3),  code  that  fits 
within  the  design.  The  analogy  holds  because: 

1.  the  Domain  Design  process  provides  specifications  for  subsystems, 
surrogates,  and  objects  to  fit  within  a  generic  design.  This  process  links 
together  portions  of  domain  models  products  into  descriptions  via  forms 
suitable  for  further  refinement.  The  specification  forms  serve  as  the 
requirements  for  the  software  entities  to  be  developed. 

2.  the  Domain  Implementation  process  provides  detailed  designs  for 
subsystems  and  surrogates  that  satisfy  the  specifications  from  the  previous 
phase.  These  designs  are  instances  of  the  OCA  subsystem  model,  using  the 
components  described  in  Section  2.3.  Although  the  production  of  code  via  the 
use  of  templates  is  the  focus  of  this  process,  the  code  is  not  tied  to  any 
specific  application  but  is  meant  to  be  usable  by  all  applications  requiring  the 
capabilities  of  the  subsystem  or  surrogate. 

3.  the  Application  Development  process  provides  code  for  an  application  that 
conforms  to  the  OCA.  This  process  binds  together  the  subsystems  and 
surrogates,  completing  those  portions  of  their  code  components  left 
incomplete  from  tire  Domain  Implementation  process,  according  to  the 
requirements  of  the  application  in  terms  of  hardware  (specific  devices), 
software  (specific  capabilities  or  features),  and  desired  performance 
characteristics.  This  process  also  involves  construction  of  the  executive, 
which  has  its  own  template  and  guidelines  for  its  completion. 

This  analogy  is  important  because  it  links  the  mapping  process  to  the  conventional  software 
development  process  as  practiced  in  most  organizations.  Hence,  the  mapping  process  is  not 
costly  to  implement  in  their  overall  process.  This  realization  within  an  overall  software 
development  should  ease  the  organizations's  transition  to  use  of  this  process.  Transition 
planning  for  this  process  is  discussed  extensively  in  [Withey  94]. 

The  next  section  describes  how  the  mapping  process  and  its  use  of  the  OCA  applies  to  the 
problems  of  developing  reusable  software. 


3.3  Um  of  the  OCA  in  the  Development  of  Reusable  Software 

The  OCA  is  a  model  for  organizing  and  implementing  the  structure  of  an  application.  Its  focus 
«  on  the  high  level  problems  of  control  and  data  flow  within  systems,  and  not  on  the 
implementation  of  low-level  functionality.  The  data  flow  is  controlled  by  the  import  and  export 
structures  via  the  controllers;  the  main  flow  of  control  is  handled  by  the  executive. 

The  executive  is  designed  to  be  a  control  structure  for  execution  of  an  application  using  the 
OCA’s  subsystem  model.  As  such,  it  does  not  have  any  visibility  to  data  items  being  used 
within  the  application  and,  therefore,  needs  access  to  only  the  Signatures  and  Controllers  for 
the  subsystems  and  surrogates  that  compose  the  application. 

The  executive  is  built  around  the  consistent  usage  of  layered  case  statements.  These  layers 
provide  a  regularity  of  form  within  the  code  that  results  in  an  executive  with  a  highly  readable, 
understandable,  and  maintainable  structure.  The  fact  that  the  subsystem  is  used  as  the 
outermost  layer  of  the  executive’s  internal  structure  provides  the  developer  with  an  easy 
mechanism  to  add  or  remove  a  subsystem;  just  add  a  new  layer  of  template  and  complete  it 
for  a  new  subsystem,  or  delete  the  entire  case  layer  and  references  to  its  operations  in  other 
layers  to  remove  it.  Appendix  C.3  further  describes  the  layers  of  the  executive. 

The  OCA  also  provides  applicable  guidance  in  the  structure  of  code  for  subsystems  and 
objects.  However,  the  OCA  does  not  enforce  any  style  for  components  below  these 
abstractions.  This  does  not  mean  that  there  is  no  appropriate  guidance  on  how  to  implement 
components  at  lower  levels.  Many  object  oriented  design  (OOD)  methods  exist  that  can  be 
used  to  create  highly  flexible  and,  hence,  reusable  components  that  would  be  applicable  for 
use  within  the  OCA.  Section  5.9  provides  further  insight  into  a  five-layered  scheme  for 
subsystems  and  their  objects  using  abstract  data  type  (ADT)  packages  and  instances  of  them. 

3.4  Benefits  from  Reusing  OCA  Structures 

There  are  two  major  benefits  to  the  use  of  the  OCA  in  developing  a  generic  design: 

1 .  consistency  of  form  within  applications,  and 

2.  separation  of  control  flow  and  data  flow. 

Each  of  these  benefits  is  discussed  in  the  following  paragraphs. 

3.4.1  Consistency  of  Form  Within  Applications 

The  use  of  templates  for  code  and  the  rigidity  of  the  OCA  in  terms  of  code  structure  may  be 
foreign  to  many  software  developers  who  are  used  to  developing  in  an  individual  or  project- 
specific  style.  However,  once  developers  become  familiar  with  the  usage  of  the  OCA,  then 
they  will  find  that  it  provides  a  solution  for  most  design  problems.  Think  about  how  much  time 
designers  have  used  answering  the  question  “How  do  I  want  this  system  to  look?"  The  normal 
answer  is  some  ad-hoc  decomposition  whose  justification  only  exists  in  the  developer's  mind 
and  will  probably  never  be  will  understood  by  future  maintainors.  The  OCA  forces  the 
developer  to  ask  a  different  question:  “How  do  I  design  this  system  using  the  OCA?"  The  OCA 
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provides  a  look  for  a  system,  and  this  look  is  consistent  for  all  systems  using  the  OCA  as  an 
design  basis.  This  means  maintained  can  make  important  assumptions  about  how  a  system 
does  what  it  does,  and  can  focus  on  understanding  what  it  does,  vastly  simplifying  the 
maintainor's  workload. 

3.4.2  Separation  of  Control  Flow  and  Data  Flow 

The  OCA  is  designed  to  separate  the  flow  of  control  (what  subprograms  get  called  in  what 
order)  from  the  flow  of  data  (where  are  the  required  inputs  and  where  do  the  results  get  put). 
Control  flow  is  implemented  in: 

•  the  Executive 

•  the  Subsystem  and  Surrogate  Controllers,  with  support  from  the  Signatures 
packages 

•  the  Object  Managers  and  the  packages  they  use  in  their  implementation 
On  the  other  hand,  data  flow  is  implemented  In: 

•  the  System  Engineering  Units  and  Subsystems  Types  packages  which 
declare  the  types 

•  the  Export  packages  which  declare  the  variables/objects  of  the  types 

•  the  Import  packages  which  map  data  type  usage  to  available  Export 
variables/objects 

•  finally  as  parameters  to  Object  subprograms  and  their  underlying 
implementation 

This  dear  separation  of  concerns  produces  an  application  with  control  and  data  flow 
responsibilities  being  relegated  to  distinct  sections  of  the  code  structure,  again  aiding 
developers  and  maintainers  in  understanding  the  system  and  where  changes  of  various  kinds 
go  within  the  code  modules  comprising  it.  Thus,  the  OCA  provides  a  consistent  system 
architecture  that  makes  the  post  deployment  software  support  process  a  much  more 
manageable  task  and  makes  for  longer  lived  systems  with  lower  costs. 

3.5  Limitations  of  the  Mapping  Process 

At  the  highest  level,  the  mapping  process  is  highly  dependent  upon  the  abstract  models  that 
are  applied  to  create  the  resulting  concrete  models.  The  process  would  need  some 
modification  to  incorporate  the  use  of  different  domain  analysis  products.  The  OCA  is  only  one 
instance  of  an  abstract  architectural  model  that  could  be  applied  to  produce  a  generic  design. 
The  mapping  process  could  be  very  different  depending  upon  the  kind  of  architecture  chosen 
because  the  later  steps  depend  heavily  upon  use  of  design  rules  and  code  templates 
associated  with  a  specific  architectural  model.  The  OCA  has  a  well-defined  component 
structure,  hi  terms  of  kinds  of  components  and  their  interactions.  This  leads  to  a  number  erf 
code  templates  to  support  the  components  and  corresponding  interaction  rules.  A  more 
kx»eiy  defined  architecture  may  have  tew  supporting  templates  and  rules.  More  work  needs 
to  be  done  to  determine  the  applicability  of  this  process  when  applied  to  different  architectures. 
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The  mapping  process  does  not  fully  specify  all  of  the  decision  making  logic  needed  to 
implement  the  process  in  an  organization  or  for  a  particular  project  or  application.  Synthesis 
steps,  where  disparate  pieces  of  information  are  combined  together,  are  generally  complete 
in  that  the  steps  state  what  information  is  being  combined  and  the  form  of  the  result  is  well 
understood.  The  analysis  steps,  however,  are  more  heuristic  in  that  they  provide  insight  into 
the  intent  of  the  step  and  a  characterization  of  the  desired  output,  but  no  precise  rules  can  be 
given  for  making  specific  decisions. 

Use  of  the  OCA  limits  the  use  of  certain  programming  paradigms  in  the  implementation  of 
subsystems  and  their  objects.  The  internals  of  objects  must  be  passive  in  that  they  cannot 
invoke  functionality  except  within  their  own  scope.  It  is  the  role  of  the  subsystem  controller  to 
coordinate  the  interaction  of  its  objects;  the  executive  coordinates  objects  in  different 
subsystems  through  the  controllers.  In  object-oriented  programming  (OOP)  terms,  methods  or 
operations  cannot  call  other  methods/operations.  This  is  to  reinforce  the  notions  that  objects 
are  only  service  providers  and  that  they  can  take  no  active  role  in  the  application’s  control  flow 
beyond  their  limited  scope. 

3.6  A  Roadmap  for  the  Details  of  the  Mapping  Process 

To  this  point,  the  focus  of  this  report  has  been  on  a  general  description  of  the  mapping 
process,  a  context  for  its  applicability  in  Model-Based  Software  Engineering,  and  an 
understanding  of  the  kinds  of  models  needed  to  describe  and  implement  the  process.  With  this 
done,  the  reader  has  a  sufficient  understanding  of  the  goals  and  intents  of  the  mapping 
process  and  the  details  of  the  process  can  be  given.  Chapter  3  begins  the  description  of  the 
process  at  a  detailed  level. 

The  use  of  domain  analysis  products  to  develop  designs  and  supporting  software  components 
prior  to  their  use  in  individual  applications  is  commonly  referred  to  as  Domain  Engineering. 
This  chapter  covers  the  steps  in  the  core  of  the  mapping  process,  which  is  applicable  to 
•  Domain  Engineering.  The  processes  and  steps  in  this  chapter  are  meant  to  be  performed 
apart  from  Application  Engineering,  which  embodies  individual  product  development. 

Chapters  4  and  5  delineate  the  steps  to  support  the  Domain  Design  and  Domain 
Implementation  processes,  respectively,  as  seen  in  Figure  3-1  and  introduced  in  Section  3.1. 
The  FODA  domain  model  provides  the  inputs  and  the  OCA's  specification  forms,  code 
templates,  and  design  rules  serve  as  the  controls  for  the  domain  engineers  who  produce  the 
generic  design  and  its  supporting  components. 

Figure  3-3  on  page  29  presents  the  OCA  structures  and  the  process  steps  discussed  in 
Chapters  4  through  6.  After  selecting  tite  capabilities  to  be  mapped  (described  in  Section  4.1), 
Figure  3-3  illustrates  the  use  of  specification  forms  that  map  the  relevant  information  from  the 
domain  model  using  steps  in  Sections  4.2  •  4.4.  The  forms  then  map  onto  the  set  of  code 
components  seen  in  Figure  3-3  by  performing  the  steps  in  Sections  5.1  -  5.9  and  in  Chapter 
6.  Each  form  or  code  component  used  (starting  with  the  templates  in  Appendices  D  and  E)  is 
marked  with  the  step  or  steps  relevant  to  its  use. 
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Figure  3-3:  Mapping  Design  Elements  to  Process  Steps 
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4  The  Domain  Design  Process 


The  Domain  Design  Process  for  subsystems  and  objects  that  fit  within  a  domain-specific 
generic  design  consists  of  4  steps,  shown  with  a  summary  of  their  actions  and  products  in 
Table  4-1. 

These  steps  map  various  portions  of  FODA  concrete  models  onto  appropriate  sections  of 
specifications  forms  for  subsystems  and  objects  (see  Appendix  D,  Sections  D.1  and  D.2, 
respectively,  for  examples  of  these  forms).  This  mapping  is  summarized  in  Table  4-2. 

The  goal  of  the  specification  forms  is  to  provide  the  software  developer  with  access  to  the 
information  needed  to  implement  functionality.  They  are  designed  with  the  assumption  that  a 
domain  model  is  in  place.  Therefore,  except  for  information  that  can  readily  be  transcribed  in 
a  succinct  way,  they  provide  references  to  information  within  the  various  products  of  a  FODA 
domain  model.  The  forms  provide  pointers  to  information  elements  about  data,  capabilities, 
and  behaviors  from  the  Information,  Features,  and  Operational  Models,  respectively. 

The  steps  listed  in  the  sections  below  are  given  in  the  order  in  which  they  should  be  performed. 
The  only  notable  exception  is  that  the  creation  of  subsystem  and  surrogate  specifications, 
described  in  Sections  4.3  and  4.4,  can  be  performed  in  either  order  or  concurrently. 


Step 

Action 

Product 

1.  Select  Features  from 
Domain 

Identify  desired  features  from  features 
model,  i.e.,  operations,  context,  and 
representation. 

List  of  desired  features 

2.  Create  Object 
Specifications 

1.  Identify  Objects 

Identify  data  items  maintaining  state 
or  requiring  explicit  control. 

Initialized  Object  Form, 
Entity  List 

2.  Derive  Object 
Operations  and 
Inputs/Outputs 

Analyze  features  model  for  operation 
variations  based  on  alternatives  or 
context  and  shown  in  operational 
model. 

Completed  Object  Form 

3.  Create  Subsystem 
Specifications 

Group  together  objects  thru  work 
together,  correlated  to  set  of  related 
features  in  features  model. 

Completed  Subsystem 
Form 

4.  Create  Surrogate 
Specifications  for 
Devices 

Determine  external  interfaces  for 
applications  and  determine  their 
control  and  data  characteristics. 

Initialized  Surrogate 

Form 

Table  4-1:  Summary  of  the  Domain  Design  Process 
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Domain  Model  Information 

Subsystem  Specification 
Form/Section 

Object  Specification 
Form/Section 

Features 

Descriptions 

Description 

Requirements 

Requirements 

Exceptions 

Exceptions 

Top-Level 

Features 

N/A 

Low-Level 

N/A 

Features 

Information  (E/R  Data) 

Objects 

Name 

Imports 

Exports 

Description 

Operational 

Imports 

Imports 

Exports 

Exports 

Exceptions 

Table  4-2:  Mapping  Domain  Model  Constructs  to  Specification  Forms 


The  description  of  each  step  in  this  specification  processes  is  given  at  a  level  above  the 
clerical  work  of  completing  the  specific  forms.  Each  step  will  be  described  as  follows: 

•  its  name  will  be  given  (in  the  title  for  the  section), 

•  a  summary  of  the  action(s)  taken  in  the  step, 

•  the  inputs)  used  in  the  performance  of  the  step,  and 

•  the  product  resulting  from  completion  of  the  step  and  how  it  contributes  to  the 
process. 

Appendix  A  contains  the  details  of  the  work  to  be  completed  at  each  step  of  the  Domain  Design 
process  concerning  the  use  of  the  forms.  Its  sections  are  numbered  to  correspond  to  the 
equivalent  step  in  the  following  sections. 

Step  0  —  Establish  an  Overall  Goal  for  the  Mapping  Process 

Before  beginning  the  mapping  process,  it  is  important  to  know  what  the  major  goal  of  the 
process  is,  because  various  alternatives  exist: 

1 .  One  can  pursue  a  limited  set  of  features  that  map  readily  to  a  core  set  of  ca¬ 
pabilities  that  are  to  be  used  in  a  product  or  as  a  domain  demonstration  (as 
done  in  the  movement  control  example).  However,  the  exclusion  of  features 
(those  not  selected)  may  impede  the  ultimate  reusability  of  the  software  if  and 
when  those  features  are  later  desired. 
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2.  One  can  indude  ail  features  of  major  capabilities  into  the  process,  which  can 
lead  to  the  most  robust  and  reusable  design  possible.  The  development  of 
such  a  design  and  its  components  would  be  a  very  difficult  task  because  of 
the  complexity  of  implementing  and  integrating  the  use  of  a  potentially  highly 
diverse  set  of  features  and  underlying  objects. 

These  two  extremes,  building  in  only  what  you  need  (as  in  1.),  and  building  in  everything  you 
could  ever  want  (as  in  2.),  have  different  success  criteria  and  cost  versus  benefit  tradeoffs,  as 
briefly  described  above.  In  an  organization  transitioning  towards  MBSE,  the  model  may  be  to 
start  more  with  a  "build  in  what  you  need"  goal  as  a  start  to  build  a  reasonable  set  of  core 
components,  transitioning  to  "build  in  everything”  as  your  organization  and  product  line 
knowledge  matures. 

Each  application  of  toe  mapping  process  probably  involves  some  combination  of  these 
alternative  process  goals  at  varying  levels  of  engineering  decision  making. 


4.1  Select  Features  from  Domain  Model 

The  selection  of  features  involves  toe  analysis  of  the  feature  and  operational  models  to 
determine: 

1 .  what  features  are  required  or  desired  in  the  software  to  be  implemented,  and 

2.  what  functionality  and  entities  are  necessary  to  deliver  those  features. 

The  feature  model  provides  the  primary  input  for  deriving  the  requirements  for  the  software  to 
be  implemented  because  they  capture  the  essence  of  user  needs  and  desires  for  the  software. 
As  described  in  Section  4.3.2  of  [Cohen  92],  there  are  three  distinct  groups  or  classes  of 
features  for  the  movement  control  domain  (and,  one  can  assume,  for  most  domains).These 
three  classes  of  features  and  their  effect  on  the  software  specification(s)  and  framework  are: 

1 .  Operations.  Those  features  that  describe  toe  functional  characteristics  of  the 
domain;  toe  services  that  a  system  must  provide. 

The  operational  features  are  essential  throughout  the  process  of  creating  the 
object  and  subsystem  specifications.  Many  of  the  steps  in  the  process  make 
direct  references  to  information  in  the  feature  model. 

2.  Context.  Those  features  that  describe  the  overall  mission  or  usage  patterns 
of  a  system;  toe  description  of  the  dass(es)  of  users  for  a  system. 

The  context  features  serve  two  major  purposes  in  this  process: 

•  They  may  drive  the  selection  of  various  operational  features,  i.e., 
omission  of  alternatives  or  options,  based  upon  toe  specific  context  to  be 
implemented  or,  conversely,  inclusion  of  multiple  alternatives  and  options 
based  upon  a  desire  to  support  a  wide  range  of  potential  contexts. 

•  They  will  manifest  themselves  In  variations  of  control  flow  in  controNers 
and  executives  as  derived  from  the  control  information  contained  in  the 
operational  model. 
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3.  Representation.  Those  features  that  describe  how  information  is  viewed  by 
the  user  or  produced  for  another  system;  what  sorts  of  input  and  output 
capabilities  are  available. 

The  representation  features  will  be  a  significant  driver  in  the  kind  and 
capabilities  of  the  physical  and  logical  devices  needed  to  support  the  resulting 
application,  and  thus  the  surrogates  needed  to  interface  with  those  devices. 
Representation  features  can  also  drive  the  aggregation  of  data  and  their 
structures  as  defined  in  the  objects. 

/ithout  knowledge  of  the  desired  features,  it  is  not  possible  to  determine  the  kinds  of  data 
needed  in  the  software  or  the  necessary  structures  or  constraints  to  be  placed  on  that  data. 

The  result  of  this  step  is  a  record  (in  no  specific  form)  of  the  selected  features.  This  record  (list, 
highlighted  features  diagram,  or  other  media)  is  used  throughout  the  remainder  of  the  Domain 
Design  process. 


4.2  Create  Object  Specifications 

Now  that  a  number  of  features  have  been  selected  for  inclusion  in  a  generic  design,  the  next 
step  in  developing  the  design  is  to  understand  how  the  features/capabilities  are  to  be  provided. 
The  service  provider  abstraction  in  the  OCA  is  the  object.  Thus,  analysis  to  locate,  understand, 
and  specify  the  objects  needed  to  implement  features  is  the  most  appropriate  step  to  perform 
at  this  point. 

4.2.1  Identify  Objects 

Those  entities  that  are  required  for  the  selected  features  and  functionality  need 
to  be  created.  Look  first  for  entities  that  are  first  and  second  entities  above 
primitive  entities.  The  primitive  entities  usually  embody  data  items  at  an 
elemental  level  of  representation,  i.e.,  numeric  values,  string  data,  etc.  The 
entities  above  these  leaves  generally  provide  useful  software  abstractions  for 
the  domain. 

The  place  to  look  for  objects  to  be  supported  is  within  the  information  model.  In  FODA,  the 
information  model  is  created  to  support  analysis  and  understanding  of  the  domain  problems 
and  to  derive  and  structure  domain  objects  used  in  the  application'5  The  primitive  entities  are 
the  leaf  items  in  the  Information  Model,  while  the  object’s  abstractions  are  found  at  various 
levels  in  the  tree-based  information  hierarchy,  as  described  in  Section  2.2. 

Higher-level  objects  may  be  constructed  from  combinations  of  lower-level  objects.  From  the 
movement  control  domain,  the  concept  of  a  road  map  involves  knowledge  of: 

1.  locations  -  names  of  places,  their  positions  in  terms  of  some  coordinate  sys¬ 
tem,  and  other  identifying  or  useful  data. 


Object  Form 

Name 

Description 


11  Sm  (Kang  901  Section  5.2.3. 
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2.  segments  -  connections  between  locations,  their  names,  and  other  useful 
information,  in  particular,  their  length. 

3.  routes  -  a  series  of  segments  that  defines  a  path  between  two  or  more 
locations  of  interest. 

4.  the  map  itself  -  a  complete  collection  of  the  locations  and  segments  in  a 
selected  geographical  region. 

ft  is  not  necessary  to  provide  an  object  for  each  entity  in  the  information  model.  There  is  an 
important  criterion  to  be  used  to  determine  whether  or  not  an  entity  in  an  information  model 
should  be  mapped  onto  an  object.  In  the  map  description  given  above,  the  locations, 
segments,  and  routes  are  easily  implemented  as  simple  information  aggregates,  such  as 
records  and  arrays  in  the  Ada  language.  Conversely,  the  map  concept  involves  the  use  of  a 
complex  structure  due  to  the  need  to  maintain  the  interrelationships  between  segments  and 
locations,  i.e.,  the  segments  know  about  which  locations  they  connect,  but  locations  may  be 
connected  to  arbitrarily  many  locations  via  multiple  segments.  The  generalized  criterion  can 
be  stated  as  follows: 

•  If  a  data  entity  can  be  implemented  as  a  simple  data  structure  with  no  extra 
functionality  required  to  support  the  abstraction, 

then  leave  it  as  an  entity,  noting  its  existence  on  an  Entity  List  for 
incorporation  into  a  System  Engineering  Units  or  _Types  package  (defined  in 
Sections  5.1  and  5.2,  respectively),  as  appropriate. 

Use  a  single  Entity  List  for  all  of  the  objects  to  be  specified  via  this  process. 

•  If  the  entity  consists  of  a  non-trivial  relation  between  data  items  where  explicit 
functionality  is  required  to  maintain  that  relationship, 

then  the  entity  should  be  allocated  to  an  explicit  object.  This  object’s  internal 
state  will  support  the  needed  relationship  via  use  of  abstract  data  type  (ADT) 
packages  in  the  implementation  of  the  object. 

Each  simple  entity  has  been  captured  on  the  Entity  List,  for  later  specification  in  a  data  type 
package.  Each  entity  selected  to  become  an  object  will  be  specified  using  a  Object 
Specification  Form,  shown  in  Appendix  0.2.  Further  specification  of  the  object,  deriving  its 
needed  operations,  is  performed  in  the  next  step,  described  in  the  following  section. 

4.2.2  Derive  Object  Operations  and  Input/Outputs 

The  operations  on  the  selected  objects  are  derived  from  two  sources: 

1.  the  selected  features  and  feature  combinations  in  the 
features  model  (from  tee  record  developed  (hiring  Step  1), 
and 

2.  by  determining  the  transformations  needed  to  support  the 
data  flows  specified  in  the  operational  model. 

The  transformations  and  the  flexibiiitiee  required  by  pertinent  features  are  synthesized  into  tee 
object’s  methods  or  subprograms  when  Implemented  in  the  selected  programming  language. 


Object  Form 

Requirements 

Features 

Imports/Exports 

Exceptions 
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The  different  classes  of  FOOA  features  may  be  handled  as  follows: 


•  All  mandatory  features  that  are  immediate  descendants  of  the  selected 
feature  are  entered  on  the  form. 

•  Alternative  features  that  are  considered  applicable  or  desirable  to  be 
incorporated  are  entered  on  the  form.  Choose  at  least  one  alternative 
feature:  otherwise,  die  parent  feature  cannot  be  correctly  mapped  into  an 
implementation.  Be  sure  to  note  that  the  feature  is  an  alternative. 

•  Optional  features  that  are  considered  applicable  or  desirable  to  be 
incorporated  are  entered  on  the  form,  noting  that  the  features  are  optional  so 
that  the  developer  can  make  the  use  of  that  feature  available  for  easy 
addition  or  deletion. 

It  is  desirable  to  attempt  to  enumerate  all  of  the  relevant  features  on  the  Object  Form.  One  can 
separate  between: 

•  features  supported  directly  in  the  implemented  object  (building  what  you 
need),  or 

•  features  supported  via  multiple  instances  of  the  object  with  various  selections 
of  feature  availability  and  underlying  implementations  (building  in  every¬ 
thing),  and 

•  those  features  not  supported  by  the  object  or  any  version. 

However,  it  will  be  very  important  to  be  able  to  trace  the  implemented  object  (and  versions)  to 
a  general  specification  of  the  range  of  capabilities  desired. 

The  Object  Specification  Forms  for  the  allocated  objects  are  complete  at  this  time.  They  are 
used  to  specify  the  Object  Manager  and  Signatures  components,  which  are  completed  within 
various  steps  of  the  Domain  Implementation  process.  Figure  3-2  on  page  24  shows  the 
migration  of  domain  information  to  these  OCA  components.  Table  4-2  on  page  32  refines  this 
migration  by  detailing  the  usage  of  the  various  sections  of  the  Object  Specification  Form. 


4.3  Create  the  Subsystem  Specifications 

As  discussed  in  Section  2.3,  a  subsystem  is  an  aggregation  of  objects. 

At  this  point,  it  is  appropriate  to  synthesize  a  grouping  of  the  objects  that 
will  be  working  together  to  perform  a  given  mission.  These  objects 
should  correlate  strongly  to  some  set  of  features  in  the  features  model 
which  are  collected  under  a  single  mid  to  high  level  feature. Depending 
on  the  scope  of  the  domain,  a  subsystem  should  correspond  to  some 
feature  In  the  feature  model  where  the  objects  to  be  aggregated  support 
the  needed  subfeatures  for  the  subsystem  encapsulating  the  selected 
parent  feature. 

For  each  input  or  output  needed  or  provided  by  a  subsystem's  objects,  determine  the 
appropriate  source  (for  imports)  or  destination  (for  exports)  subsystem  using  the  operational 
model.  This  step  may  be  deferred  untM  the  appRcation  is  further  defined  because  the 


Subsystem  Form 

Name 

Description 

Requirements 

Imports/Exports 

Exceptions 
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applicable  input  source  may  not  be  defined  until  ail  subsystems  and  surrogates  have  been 
delineated.  However,  it  is  imperative  that  aU  required  inputs  be  noted  so  that  system 
completeness  can  be  determined,  that  is  that  ail  inputs  for  subsystems  have  at  least  one 
source  from  some  other  subsystem  or  surrogate. 

The  completed  Subsystem  Specification  Form,  shown  in  Appendix  D.1,  is  produced  by 
performing  this  step.  Figure  3-2  on  page  24  shows  the  mapping  of  domain  information  to  the 
OCA  subsystem  components  at  an  overall  level.  Table  4-2  on  page  32  details  the  data 
captured  within  the  various  sections  of  the  Subsystem  Specification  Form. 

4.4  Create  a  Surrogate  Specification  for  Each  Logical/Physical 
Device 

This  step  specifies  an  abstract  view  of  a  logical  or  physical  device  that  Surrogate  Form 
is  to  be  part  of  an  application  within  a  domain.  These  devices  include 

Mama 

text  or  graphics  terminals  with  keyboards,  pointing  mechanisms,  disk 
drives,  and  communications  mechanisms.  The  use  of  such  devices  _  "P 
may  be  an  integral  part  of  the  total  application.  For  example,  any  (/o  Connections 
program  that  interacts  with  a  user  and  uses  previously  stored  data  jmports/Exports 
needs  two  surrogates:  Exceptions 

1.  one  for  the  user  interaction  device,  i.e.,  the  terminal/keyboard,  and 

2.  another  for  some  form  of  persistent  data  storage. 

The  isolation  and  abstraction  of  such  devices  is  an  important  step  in  the  creation  of  a 
consistent  framework  for  use  by  multiple  applications  in  a  domain. 

There  are  two  important  lands  of  information  needed  for  the  analysis  to  specify  the  abstraction 
to  be  embodied  within  a  surrogate: 

1 .  the  control  characteristics  of  the  device  to  be  abstracted.  These  characteris¬ 
tics  will  be  identified  using  the  following  terms: 

a.  a  monitor  device  -  a  device  which,  upon  receiving  an  appropriate 
stimulus  from  an  external  source,  causes  the  application  to  receive 
control  signals  and/or  data  to  which  the  application  should  respond. 

Such  devices  are  nominally  thought  of  as  input  devices. 

b.  a  control  device  -  a  device  which,  upon  receiving  an  appropriate 
stimulus  from  the  application,  causes  the  device  to  send  control 
signals  and/or  data  to  an  external  destination.  Such  devices  are 
nominally  thought  of  as  output  devices. 

c.  a  device  that  exhibits  both  of  the  above  behaviors;  a  device  that 
performs  both  input  and  output  functions. 

Also,  consider  whether  the  device  behaves  in  a  synchronous  or 
asynchronous  manner. 


2.  the  data  characteristics  of  the  device,  in  terms  of  both: 

a.  the  physical  characteristics  of  the  initial  input  or  final  output,  in  terms 
of  size  (of  the  device’s  buffer  area,  if  any)  and  layout. 

b.  the  logical  characteristics  of  the  final  input  or  initial  output,  i.e.,  its 
form. 

The  implementation  details  of  how  the  control  signals  and  data  are  transformed  from  formats 
usable  within  the  application  to  the  format  needed  by  the  device  being  abstracted,  and  vice 
versa,  are  what  is  hidden  by  the  packaging  under  the  surrogate  specification. 

The  identification  of  surrogates  can  come  from  several  different  areas  in  the  domain  model 
and  the  products  that  comprise  it.  The  representation  features  in  the  feature  model  can  identify 
the  needs  for  operations  that  must  be  provided  by  user  interface  devices  with  varying  degrees 
of  capability,  text,  and/or  graphics.  The  need  for  persistent  data,  shown  in  the  operational 
model,  requires  a  surrogate  to  handle  data  storage  and  retrieval  operations. 

The  completed  Surrogate  Specification  Form,  shown  in  Appendix  D.3,  is  the  result  of  this 
step.The  mapping  of  needed  information  from  the  domain  model  is  very  similar  to  that  for 
subsystems,  as  described  in  the  previous  step. 
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5  The  Domain  Implementation  Process 


The  steps  in  the  previous  section  describe  the  Domain  Design  process,  which  derives  the 
specifications  for  the  three  logical  abstractions  within  the  OCA:  objects,  subsystems,  and 
surrogates.  The  following  section  will  describe  the  Domain  Implementation  process  of 
mapping  the  information  in  those  forms  onto  Ada  templates  for  the  component  structures  in 
the  OCA  implementation. 


Step 

Action 

Product 

1.  Identify/Create 

Engineering  Units 

Identify  low-level  units  of  measure  or 
base  data  types  from  Information 
Model  and  Context  features  and  create 
or  select  packages  to  handle  them. 

Reuse  of  applicable  data 
types  across  subsystem 
boundaries 

2.  Create  Subsystem  JTypes 

Identify  data  types  needed  for  object 
operations  visible  to  subsystem 
externals  and  create  definitions. 

Encapsulation  of 
subsystem  data  types 

3.  Create  Object  Signatures 

Create  namespace  for  selecting  object 
operations  alternatives  from  the 
Features  To  Be  Supported  items. 

Encapsulation  of  object 
operational  variations 

4.  Create  Manager 
specification 

Create  object  operation  profiles  using 
consistent  naming  and  with  needed 
parameters  (data/features). 

Specification  of  Object 
abstraction 

5.  Create  Subsystem/Surrogate 
Signatures 

Export  Object  feature  information  and 
create  namespace  to  document  data 
entities  manipulated  by  the  sub¬ 
system’s  objects. 

Specification  of 
Subsystem  entities  and 
operational  variations 

6.  Create  Subsystem/Surrogate 
Controller  specification 

Create  subsystem  operation  profiles 
using  consistent  naming  and 

Signature  parameters. 

Specification  of 
Subsystem  abstraction 

7.  Create  Subsystem/Surrogate 
Import/Export  packages 

Create  support  for  acquiring  needed 
inputs  for  operations  and  making  out¬ 
puts  visible  to  others. 

Encapsulation  of  data 
interface  functionality 

8.  Create  Subsystem/Surrogate 
Controller  package  body 

Create  sequences  of  object  operations 
to  achieve  subsystem  requirements, 
importing  and  exporting  data  as 
needed  following  operational  model. 

Implementation  of 
Subsystem  internals 

9.  Create  Manager 
implementation 

Implement  object  operations  using 
low-level  components/ ADTs,  etc. 
following  operational  model. 

Implementation  of 

Object  internals 

The  Domain  Implementation  process  of  mapping  specifications  for  the  subsystems  and 
objects  onto  the  OCA  and  its  Ada  code  constructs  consist  of  nine  steps,  shown  with  a 
summary  of  their  actions  and  products  in  Table  5-1 .  The  steps  in  the  process  are  given  in  an 
order  that  allows  the  developer  to  complete  a  code  unit,  usually  by  filling  out  a  template,  and 
then  compile  the  resulting  source  code  it  into  a  program  library-  Subsequent  code  units 
developed  in  this  process  can  make  use  of  these  previous  results. 

The  Ada  language  incorporates  the  notion  of  a  package  construct  as  a  group  of  logically 
related  type,  object,  and  subprogram  declarations.  Other  languages,  such  as  C++  or  Modula- 
2  have  an  equivalent  notion  and  corresponding  construct,  such  as  the  class  or  module.  In 
addition,  these  languages  also  provide  the  equivalent  of  the  separation  of  concern  between 
specification  of  operations  and  their  implementation  seen  in  the  Ada  package  specification 
and  body,  as  illustrated  in  the  steps  shown  in  Table  5-1 .  Modula-216  defines  the  separation  in 
terms  of  distinct  definition  and  implementation  modules.  C++17  clearly  defines  (in  a  less  formal 
manner)  the  class  interface  (or  header,  placed  in  a  .  h  file)  and  implementation  (placed  in  a  .  c 
file).  Whenever  these  steps  refer  to  the  terms  package  specification  or  package  body,  one  can 
refer  to  use  of  the  equivalent  structures  in  other  programming  languages. 

The  first  six  steps  of  the  Domain  Implementation  process  involve  the  bottom-up  construction 
of  code  unit  specifications  up  to  the  level  of  the  subsystem  controller.  The  last  three  steps  are 
a  top-down  refinement  process  of  developing  supporting  package  specifications  and  bodies, 
i.e.,  the  import  and  export  areas,  and  the  bodies  of  the  package  for  the  subsystem  controller 
and  the  object  manager  (implementation  details  discussed  in  the  appropriate  section  and/or 
corresponding  appendix  section). 

Steps  3, 4,  and  9  are  performed  for  each  Object  Specification  Form  derived  from  the  previous 
process.  Steps  2,  5,  6  and  6  are  performed  for  each  Subsystem  or  Surrogate  Form.  Much  of 
the  actual  work  of  surrogate  development  is  deferred  until  the  application  structure  is 
completely  defined  and  will  be  described  further  in  Chapter  6. 

These  nine  steps  map  information  on  specifications  forms  for  subsystems  and  objects  onto 
various  constructs  within  the  resulting  code  structures.  This  mapping  is  summarized  in  Table 
5-2  on  the  following  page. 

The  description  of  each  step  in  this  process  is  given  at  a  level  above  the  clerical  work  of 
completing  the  specific  template(s).  Appendix  A.2  contains  the  details  of  the  work  to  be 
completed  at  each  step  concerning  the  use  of  the  Ada  templates.  Its  sections  are  numbered 
to  correspond  to  the  equivalent  step  in  the  following  sections.  As  in  Chapter  4,  each  step  will 
be  described  in  terms  of  its  name,  actions,  inputs,  and  product.  Each  step  results  in  a 
completed  OCA  component  as  a  product  except  for  Import  bodies  and  surrogate  components 
which  are  completed  during  the  Application  Development  process  described  in  Chapter  6. 

18  See  IWkth  85]  for  further  details  on  the  Modula-2  language. 

17‘  See  [Stroustrup  91]  for  further  (Mailt  on  the  C++  language. 
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Specification  Form/Section 

Source  Code  Construct 

Subsystem 

Requirements 

Controller 

Features 

Controller 

Signatures 

Objects 

Signatures 

Types 

Imports 

Imports 

Exports 

Exports 

Exceptions 

Signatures 

Object 

Requirements 

Manager  (procedures) 

Features 

Signatures 

Imports 

Manager  (procedure  parameters) 

Exports 

Manager  (procedure  parameters) 

Exceptions 

Manager  (exceptions  declared  within  the 
Manager  and  propagated  by  procedures) 

Table  5-2:  Mapping  from  Specification  Forms  to  Code  Constructs 


5.1  Identify  or  Create  Applicable  System  Engineering  Units 
Packages) 

The  goal  of  developing  a  System  Engineering  Units  (SEU)  package  is  to  gather  together  the 
information  about  the  basic  elements  of  data  that  are  commonly  used  as  parts  of  many  other 
abstractions  in  software  systems.  The  inputs  are  the  Entity  List,  which  specifies  the  need  for 
various  data  items,  and  the  Information  Model,  which  specifies  the  characteristics  for  the  data. 

Many  of  the  low-level  parts  of  data  items  within  typical  software  systems  are  probably 
derivable  from  a  relatively  small  number  of  data  types  whose  usage  spans  many  domains. 
Various  units  of  measure,  such  as  feet  or  meters  depending  on  which  measurement  system 
the  software  is  to  support,  and  the  operations  needed  to  support  their  use,  are  prime 
examples. 


There  is  no  standard  name  for  this  package  because  it  may  not  be  prudent  to  put  all  of  the 
shared  or  common  types  into  a  single  package.  In  the  movement  control  example,  type 
declarations  of  this  nature  were  built  into  three  packages: 


1.  Measurements ypes  -  a  package  of  basic  units  of  measure  such  as  length, 
weight,  and  speed,  which  are  available  in  both  metric  and  English  units  and 
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scales,  and  which  provides  a  flexible  mechanism  for  using  and  changing  be¬ 
tween  the  units. 

2.  Vehicle-Types  -  a  package  which  encapsulates  the  highly  variant  structure  of 
the  hierarchy  of  information  that  can  be  stored  as  part  of  the  many  different 
views  a  vehicle  may  have  witoin  the  Army  command  structure. 

3.  Default  -  a  package  which  provides  useful  constants  for  various  instances  of 
Vehicle_Types. 

The  identification  of  data  types  that  should  become  part  of  this  package  or  set  of  packages 
(depending  on  the  number  and  layering  of  data  types  needed)  can  be  identified  by  examining 
the  Entity  List,  developed  during  the  Identify  Objects  step  in  Section  4.2.1 ,  for  those  data  items 
that  are  used  by  multiple  subsystems.  Developers  should  attempt  to  reuse  packages  that 
provide  the  required  data  types  wherever  possible.  Some  good  examples  are  the 
Basic_Data_T ypes  and  the  many  mathematical  packages  available  from  the  CAMP  project 
(see  [McNicholl  88]).  Otherwise,  the  developers  must  implement  them  directly.  [Gautier  90] 
contains  a  suitable  set  of  guidelines  for  development  of  Ada  packages  with  specific  rules  for 
generics  and  a  strong  focus  on  reusability. 

The  result  of  this  step  is  the  selection  of  reusable  data  type  packages  to  be  used  throughout 
the  OCA  components  These  packages  specify  many  of  the  data  types  to  be  transferred 
between  the  import  and  export  packages  for  subsystems  and  surrogates  and  the  parameters 
used  by  object  operations. 


5.2  Create  Subsystem  _  Types  Package 

The  process  and  inputs  for  creating  this  package  are  similar  to  that 
just  described  for  creating  the  System  Engineering  Units  or 
Common_Types  package(s).  The  key  result  is  to  provide  a  suitable 
type  definition  for  those  entities  that  will  be  used  with  a  single 
subsystem. 

Allocate  all  of  the  remaining  data  items  in  the  Entity  List  to  the  appropriate  subsystem’s 
“-Types*  package  and  create  a  suitable  type  declaration  for  each  item,  referring  to  the 
Information  Model  for  the  needed  data  characteristics. 


| Types  | 

0 

E7 

1 - 1 

[ 

Controller 

Notice  that  all  of  the  data  structures  that  will  be  passed  between  subsystems  and  surrogates 
have  been  defined  in  these  two  steps.  Those  data  items  that  are  used  by  multiple  subsystems 
are  defined  first  in  various  SEU  packages.  Then,  those  items  that  are  used  only  in  one 
subsystem  are  defined  in  specific  JTypes  packages.  Surrogates  are  an  exception  in  that  they 
need  access  to  the  data  types  of  all  subsystems  to  which  they  are  to  provide  their  services. 
Thus,  the  import  and  export  packages  and  the  controller  package  body  for  a  surrogate  will 
incorporate  type  information  from  each  subsystem  JTypes  package  as  needed  to  implement 
the  needed  operations  for  the  surrogate. 


5.3  Create  Object  Signatures  Package 

The  Signatures  package  at  the  object  level  of  the  OCA  captures  the  use 
of  features  that  imply  a  selection  from  alternative  algorithms  or  other 
information  used  to  control  the  execution  of  an  operation,  e.g.  control 
information.  As  an  example,  consider  the  operation  of  selecting  a  route 
between  two  points  (following  the  logical  map  structure  described  in 
Section  4.2.1). 

The  movement  control  domain  model  in  [Cohen  92]  describes  two  alternative  subfeatures  for 
the  route  selection  feature,  best  and  satisfice.18  Computer  science  has  two  terms  that  are 
synonymous  with  these  notions,  optimal  and  heuristic.  A  best  (or  optimal)  solution  should 
guarantee  the  most  accurate  results  possible,  at  the  cost  of  high  (or  perhaps  prohibitive) 
computational  time.  Conversely,  a  satisfice  (or  heuristic)  solution  may  provide  a  result  that  is 
less  than  optimal  yet  is  satisfactory  for  the  intended  purpose,  and  has  the  property  of  being 
solvable  u.  an  appropriate  time  period.  The  selection  of  the  best  or  satisfice  feature  has 
nothing  to  do  with  the  data  (in  this  case  the  points  selected  as  start  and  end  points  and  any 
others  to  be  visited  along  the  way).  The  feature  selection  has  to  do  only  with  the  algorithm  used 
to  produce  the  desired  results,  i.e.,  control  of  the  application.  This  is  the  intent  of  the  use  of 
features  in  FOOA,  the  selection  of  appropriate  functionality  according  to  the  user’s  desires. 

The  Object  Signatures  package  captures  the  flexibility  of  an  Object  Manger’s  functionality.  The 
Signatures  package  creates  the  namespace  for  identifying  the  existence  of  features,  keeping 
separate  from  the  code  that  creates  and  implements  the  operations  that  satisfy  those  features. 

Building  the  Object  Signatures  packages  is  a  straightforward  process.  For  each  named  feature 
from  the  Object  Specification  Form,  create  a  corresponding  name  within  the  Object  Signatures 
package.  If  an  object  has  no  features,  i.e.,  alternative  implementation  calls  or  optional 
processing,  then  no  Signatures  package  is  required. 

Creation  of  Object  operations  begins  with  the  next  step,  as  described  below. 

5.4  Create  Object  Manager  Package  Specification 

The  intent  of  the  Object  Manager  is  to  provide  a  standard  mechanism  for 
invoking  the  operations  needed  to  provide  the  services  for  the 
physical/logical  object  that  is  to  become  a  part  of  a  system.  Use  of  a 
standard  mechanism  provides  two  major  benefits: 

1.  It  allows  the  use  of  a  predefined  set  of  operations/names  that  give  objects  a 
consistent  set  of  operational  semantics.  This  enables  objects  that  implement 

ia  The  word  satisfice  is  defined  as  to  decide  an  and  pursue  a  course  of  action  that  wtt  satisfy  the  minimum 
requirements  necessary  to  achieve  a  particular  goal  [OED  87].  This  word  and  its  definition  are  attributable  to 
Nobel  laureate  Dr.  Herb  Simon,  wrtw  has  used  It  in  many  contexts,  inducting  finding  various  classes  of  solutions 
to  combinatorial  problems  ([Simon  81],  Chapter  S,  p.  138.) 


even  highly  different  abstractions  to  be  common  building  blocks  tor  multiple 
applications  due  to  the  external  similarities. 

The  development  of  this  consistent  namespace  for  object  (and  eventually 
subsystem)  operations  involves  an  analysis  that  is  beyond  the  scope  of  this 
report  (see  Limitations  in  Section  3.5). 

2.  It  results  in  a  great  increase  in  the  understandability  and  maintainability  of  the 
subsystem  operations  that  utilize  the  object’s  (via  the  manager)  operations  in 
their  implementations. 

The  need  for  parameters  for  the  operations  is  defined  by  the  lists  of  Imports  and  Exports  in  the 
Specification  Form  tor  the  object.  Using  the  Operational  Model  to  provide  the  precise  needs 
for  inputs  and  outputs  for  each  operation,  fill  in  the  parameter  profiles  for  each  operation 
specified  in  the  code  template.  If  an  object  handles  multiple  entities,  then  each  predefined 
subprogram  will  be  overloaded  to  handle  each  of  the  entities  to  be  stored  and/or  manipulated 
by  the  Object  via  Manager  calls.  Also,  for  each  type  of  object  feature,  add  a  parameter  of  mode 
‘in’,  using  a  default  parameter  value  if  a  particular  feature  is  nominally  used  at  invocation. 

Using  the  information  on  the  Object  Specification  Form,  verify  that  each  mandatory  feature  is 
allocated  to  one  (or  more)  subprograms  and  that  specified  optional  or  alternative  features  are 
similarly  supported  via  use  of  feature  parameters  in  the  appropriate  subprograms.  Finally, 
ensure  that  there  exists  a  version  of  the  applicable  subprograms  for  each  entity  allocated  to 
the  Object  Manager. 

5.5  Create  Subsystem/Surrogate  Signatures  Package 

As  discussed  previously  in  Section  5.3,  the  Signatures  package  is  a 
mechanism  for  creating  a  namespace  to  be  used  by  the  executive 
to  achieve  precise  control  of  the  subsystem.  The  executive 
achieves  this  control  via  the  passing  of  control-related  information 
from  the  executive  to  subsystems  and  their  underlying  objects 
during  procedure  invocation.  The  process  to  be  followed  for 
creating  a  Signatures  package  is  similar  to  that  described  earlier  for 
Objects.  The  features  named  on  the  Subsystem  Form  are  mapped 
onto  operation  names  or  to  features  names  to  be  passed  down  to 
invoke  alternative  or  optional  sets  of  Object  operations. 

For  the  Subsystem  Signatures,  there  is  the  additional  responsibility  of  incorporating  any 
Object  Signatures  packages  and  their  information  into  the  Subsystem  package  and 
reexporting 19  them  for  use  in  the  executive.  Reexporting  makes  the  various  type  names  and 
enumeration  literals  from  the  associated  Object  Signatures  packages  directly  visible  at  the 
subsystem  level.  The  effect  of  reexporting  the  types  and  literals  from  the  Object  Signature 
packages  is  to  minimize  the  need  for  other  subsystems  and  surrogates  or  the  executive  to 

1B'  See  (Bardin  87a]  and  [Bardin  87b]  for  an  explanation  of  the  concept  of  reexporting  and  for  an  extended 
example  of  its  application,  respectively. 
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require  visibility  to  the  Object  Signatures,  i.e.,  using  the  with  (as  in  Ada)  or  indude  (as  in  C++) 
syntax  to  reference  the  signature  information.  Reexporting  simplifies  the  usage  of  the 
subsystem  by  centralizing  all  of  the  Signatures  information  into  a  single  entity,  the  Subsystem 
Signatures  package. 

A  User  Interface  (Ul)  Surrogate  Signatures  package  provides  a  good  example  of  the  use  of 
signatures  in  the  OCA.  The  Ul  is  a  focal  point  for  control  information  in  that  the  user’s  input  in 
terms  of  menu  selections,  button  clicks,  etc.,  must  be  transferred  in  a  form  usable  by  the  ap¬ 
plication's  executive.  Similarly,  errors  that  the  user  must  be  informed  of  need  to  be  trans¬ 
formed  into  device-usable  formats.  Thus,  the  Ul  Surrogate  Signatures  is  a  complex  structure 
that,  in  many  cases,  requires  a  great  deal  of  knowledge  about  the  application  as  a  whole.  Its 
Status.Value  is  a  variant  record  structure  that  contains  the  equivalent  of  the  selected  menu 
option,  keystroke,  etc.,  that  are  to  be  processed  by  the  application  as  a  user  command.  All 
subsystems  whose  operations  are  invoked  by  the  user  via  the  Ul  surrogate  must  become  part 
cf  the  surrogate’s  namespace.  Also,  the  information  needed  to  construct  appropriate  error 
messages  must  be  in  the  Signatures  package. 

A  surrogate  depends  upon  information  from  subsystems  it  is  to  support;  therefore,  it  will  not 
be  possible  to  completely  define  a  surrogate  until  all  of  the  subsystems  that  will  become  part 
of  an  application  are  selected  and  defined,  e.g.,  a  complete  surrogate  is  bound  to  a  specific 
instance  (at  the  subsystem  composition  level)  of  an  application  architecture.  Consequently, 
the  addition  or  removal  of  a  subsystem  to  an  application  will  (in  all  probability)  affect  one  or 
more  of  the  application  surrogates.  This  does  not  mean  that  a  surrogate  is  application-specific; 
just  that  there  is  some  degree  of  coupling  between  subsystems  and  the  surrogates.  This 
coupling  is  well  defined  and  is  described  in  Section  6.2  where  the  surrogates  are  completed. 


5.6  Create  Subsystem/Surrogate  Controller  Package  Specification 

The  Subsystem  Controller  provides  a  uniform  interface  to  the 
underlying  capabilities  of  the  subsystem.  Again,  the  use  of  a 
predefined  namespace  for  the  subsystem  provides  for  consistent 
names  across  subsystems,  just  as  for  objects  as  discussed  in 
Section  5.4.  The  procedures  declared  in  the  Controllers  use  the 
entities  declared  in  the  Signatures  package  as  parameters.  The 
parameters  will  be  used  in  the  Controller  body  to  determine  which 
Object  operation(s)  need  to  be  invoked  to  fulfil!  the  required 
functionality. 

For  surrogates,  the  process  is  essentially  equivalent  to  that  for  subsystems.  Again,  some 
amount  of  work  must  be  deferred  until  the  application  is  defined,  since  each  of  the  two  device 
control  procedures,  Application_To_Device  (for  control  surrogates)  and 
Device_To_Application  (for  monitor  surrogates),  is  overloaded  for  each  functional  subsystem 
that  is  part  of  the  application  architecture.  Also,  because  for  some  subsystem  operations  we 
need  to  distinguish  between  differing  kinds  of  information  relating  to  the  same  entity,  we  may 
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need  to  use  an  alternative  form  of  the  Devi  ce_To_Ap  plication  procedure.  This  second 
overloaded  form  allows  an  incomplete  yet  useful  amount  of  entity-related  information  to  be 
transferred  into  the  application  versus  a  complete  data  item.  This  alternative  is  useful  in 
passing  search  key  information  into  the  application  for  use  by  a  subsystem  in  searching  for 
and  locating  a  desired  piece  of  information  in  a  large  information  aggregate  so  that  a  complete 
record  can  be  returned,  hence  the  use  of  the  term  Key  in  the  Data_Kind  declaration  seen  in 
the  template  in  Appendix  E.3. 

5.7  Create  Subsystem/Surrogate  Import  and  Export  Packages 

As  discussed  in  Sections  2.3.2.3  and  2.3.2.4,  the  Import  and  Export 
packages  provide  the  mechanism  for  bringing  data  into  and  getting 
it  out  of  the  subsystem  or  surrogate;  there  is  no  difference  in  their 
implementation,  other  than  when  in  this  process  they  can  be 
completed.  The  subsystems  can  essentially  be  completed  at  this 
point,  whereas  the  completion  of  the  surrogates  must  be  deferred 
until  the  application  context  is  further  defined. 

The  Export  package  is  completed  first.  The  need  for  a  data  item  to  be  exported  is  defined  by 
the  Export  and  Destination  information  in  the  Subsystem  or  Surrogate  form  The  Export 
package  creates  a  visible  reference  to  data  values  of  use  to  other  parts  of  the  application.  The 
content  of  the  declared  data  items  is  determined  via  calls  to  subsystem/surrogate  operations. 
There  are  two  basic  methods  for  exporting  data  within  the  OCA: 

1 .  One  can  simply  supply  declared  variables  which  are  directly  visible  within  the 
package. 

2.  One  can  supply  functions  that  return  an  applicable  value.  The  functions  hide 
any  visibility  to  the  variables  themselves  and  can  be  used  to  implement 
indirect  and/or  mutually  exclusive  access  to  the  data. 

The  Import  package  is  completed  in  two  parts.  The  specification  or  declaration  part  creates 
the  function  name  (one  for  each  data  type  listed  in  the  Imports  section  of  the  Subsystem 
Form).  The  function  will  be  invoked  by  the  Controller  to  gain  access  to  the  data  value  specified 
by  the  return  type  (one  for  each  data  type  required  by  one  or  more  subsystem  operations.  The 
body  supplies  a  reference  to  a  data  value  of  the  required  type),  either  directly  by  naming  a 
variable  created  in  another  subsystem’s  Export  package,  or  indirectly  by  calling  the  function 
supplied  by  the  Export  package.  In  either  case,  the  knowledge  of  where  a  data  item  comes 
from  is  hidden  at  a  level  where  it  is  easily  modified  and  has  minimal  effect  to  the  remainder  of 
the  application  code.  The  body  part  is  completed  in  Section  6.2.4  for  subsystems.  For 
surrogates,  completion  of  the  import  and  export  packages  is  deferred  until  Section  6.2.3. 
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5.8  Create  Subsystem/Surrogate  Controller  Package  Body 

The  Subsystem  Controller  body  is  where  the  binding  occurs 
between  the  objects  that  provide  the  services  and  the  needed 
imports  and  exports  needed  to  make  the  services  perform  work. 

Thus,  the  recurring  theme  in  implementing  a  Controller  body  will  be 
centered  about  the  following  sequence: 

1 .  Take  in  the  entity  (and  feature(s))  parameters  eventually  to 
be  passed  in  by  the  call  from  the  Executive,  defined  in  the 
operational  and  feature  models,  respectively. 

2.  Based  upon  the  given  parameters,  select  the  appropriate  Object  operation  to 
call. 

3.  Call  the  selected  operation,  using  appropriate  Import  functions  to  satisfy  the 
input  parameters  and  Export  variables  to  receive  output  results. 

4.  If  no  exception  is  raised,  ensure  the  state  of  the  subsystem  is  indicated  as 
Normal,  or  handle  any  propagated  exception  by  either  issuing  other  Object 
calls  to  dean  up  the  Object  state  or  setting  the  IntemaLState  to  a  meaningful 
Status_Type  for  examination  and  action  by  the  Executive  when  the  Signal 
function  is  called. 

The  steps  for  completing  a  Surrogate  Controller  body  are  less  clear  due  to  the  differing  nature 
of  what  a  surrogate  is  to  accomplish  in  terms  of  the  multiple  of  different  capabilities  presented 
by  various  devices.  Thus,  these  steps  are  much  less  predse  than  those  given  in  other  sections 
of  this  report,  but  they  will  still  provide  some  guidance  to  the  implementor  of  the  surrogate. 

1 .  Plan  to  develop  a  surrogate  in  either  one  of  two  ways: 

a.  One  style  is  to  encapsulate  the  device  characteristics  into  a  single 
Handler  package  using  the  information  on  device  characteristics  and 
buffer  size  given  on  the  Surrogate  Specification  Form  and  develop  a 
Transforms  package  for  each  subsystem  and  its  data  entities  to  be 
handled  by  the  device.  This  approach  is  recommended  for  devices 
that  have  a  single  set  of  fairiy  immutable  characteristics  where  those 
charaderistics  are  best  located  in  a  central  location.  This  approach 
was  used  in  the  User  Interface  Surrogate  (see  Section  F.1.1  for  a 
discussion  of  data  interfaces  used  in  the  user  interface). 

b.  An  alternate  approach,  suitable  for  disk  systems  whose  file  formats 
are  highly  flexible,  is  to  develop  a  Handler  and  Transforms 
combination  package  for  each  subsystem.  This  approach 
acknowledges  the  fact  that  there  is  a  single  logical  device  (with 
potentially  asynchronous  behavior)  that  should  be  encapsulated  in  a 
controller,  but  the  flexibility  of  the  device  precludes  the  need  for  a 
single  Handler  package,  i.e.,  each  file  type  or  set  of  related  files  to  be 
used  is  implemented  as  a  separate  package. 
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2.  The  namespace  for  device  Handler  and  Transforms  package  is  less  rigid  than 
the  namespace  used  for  subsystem  controllers  and  object  manager 
operations.  It  is  important  to  develop  a  consistent  namespace  for  use  within 
a  single  surrogate,  but  the  names  need  not  be  consistent  across  different 
surrogates.  For  example,  the  notion  of  Read,  Write,  Open  and  Close 
operations  are  highly  useful  when  thinking  about  file  systems,  whereas  Get 
and  Put  or  Send  and  Receive  operations  are  more  applicable  to  other  kinds 
of  devices. 

Also,  since  the  surrogate  will  need  knowledge  of  the  specific  application  to  be  complete,  the 
remaining  portion  of  die  surrogate  development  must  be  deferred  until  a  specific  application 
(in  terms  of  subsystems/features)  is  to  be  developed. 

5.9  Create  Object  Manager  Package  Body 

The  Object  Manager  body  is  where  the  binding  occurs  between  the 
specific  algorithms  and/or  abstract  data  types  (ADTs)  to  be  used  to 
implement  operations  and  the  data  types  and  constructs  of  the  OCA. 

Therefore,  the  bulk  of  the  completion  of  its  internals  is  left  to  the 
implementor  using  any  design  approach  or  method  that  produces 
components  that  will  integrate  into  the  OCA  subject  to  the  limitations 
described  in  Section  3.5. 

From  this  point  on,  the  package  implementor  has  to  ‘with’  in  any  additional  packages 
containing  the  algorithms  and  ADT  operations  desired  to  complete  the  construction  of  the 
operation  subprograms  in  accordance  with  the  requirements/features  allocated  to  the  object. 
This  includes  appropriate  performance  or  system  features  such  as  constrained  memory 
usage. 

A  subsystem  controller  is  designed  to  be  the  top  level  of  a  hierarchy  of  code  units  supporting 
the  application  executive.  Each  level  in  the  hierarchy  provides  specific  resources  or 
encapsulating  lower  level  resources.  Figure  5-1  illustrates  the  implementation  of  this  hierarchy 
with  an  example,  again  drawn  from  the  movement  control  domain. 

The  Subsystem  Implementation  Model  depicts  the  contents  of  the  Object  Manager  and  the 
relationships  between  the  components  that  form  its  contents  and  to  the  subsystem  controlling 
the  object.  The  bottom  two  layers  of  the  hierarchy,  Basic  Operations  and  Data  Types,  provide 
ADT  services  (usually  in  the  form  of  Ada  generics)  and  type-specific  declarations  and  services, 
respectively,  to  the  next  two  layers,  Utilities  and  Objects.  The  Utilities  layers  provide  an  area 
where  generic  objects  can  be  formulated  and  those  generics  instantiated  as  needed  prior  to 
use  within  an  Object  Manager  at  the  Objects  level.  The  Object  layer  is  where  the  use  of  Utilities 
and  Data  Types  are  combined  into  meaningful  abstractions  for  use  by  the  Subsystem. 
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Figure  5-1:  Subsystem  Implementation  Model 

The  structure  of  objects  is  less  regular  than  that  of  subsystems  or  surrogates  as  defined  by 
the  OCA.  The  Subsystem  Implementation  Model  shown  here  describes  the  kind  of 
relationships  and  dependencies  that  can  exist  at  the  Object  level.  The  Utilities,  Data  Types, 
and  Basic  Operations  layers  are  an  attempt  to  capture  these  relationship  in  an  object-oriented 
m<  Ter.  Again,  the  purpose  of  an  object  is  to  model  an  important  entity  in  an  application.  It  is 
not  possible  to  rigorously  define  the  implementation  of  an  object  because  of  the  wide  variance 
in  what  objects  are  needed  in  domains  and  how  they  are  characterized  in  software.  The 
Subsystem  Implementation  Model  of  the  OCA  provides  guidance  on  the  kinds  of  software 
components  that  can  be  used  to  implement  domain  objects  in  software. 


6  Application  Development  Using  a  Generic  Design 


The  previous  two  chapters  described  processes  for  taking  information  from  the  domain  model 
and  transforming  it  into  design  and  code  units  (at  varying  degrees  of  completeness)  that  are 
to  become  the  building  blocks  for  the  development  of  actual  applications  in  the  domain.  The 
following  sections  describe  the  Application  Development  process,  which  completes  any 
unfinished  blocks  and  assembles  them  into  a  cohesive  application.  This  process  consists  of 
three  major  steps,  shown,  along  with  a  summary  of  their  actions  and  products,  in  Table  6-1 . 


Step 

Action 

Product 

1 .  Create  Application 

Signatures 

Determine  needed  subsystems  and 
surrogates.  Document  operation 
namespace.  Determine  executive 
statespace. 

Context  for  Application 

2.  Complete 

1.  Surrogate  Signatures 

2.  Surrogate  Controller 
specification 

3.  Surrogate  Import/Export 

4.  Subsystem  Import  body 

3.  Surrogate  Controller  body 

Determine  data  items  to  be  handled. 
Determine  control  feedback  needs 
to  executive  Determine  error 
handling  information  needs. 

Create  surrogate  operation  profiles 
using  given  names  and  data  item 
namespace. 

Use  operational  model  to  determine 
required  external  inputs/outputs. 

Complete  mapping  of  sources  for 
required  inputs. 

Create  sequence  of  transforms  for 
handler  operations. 

Namespace  to  describe 
device  capabilities 

Specification  of 

Surrogate  abstraction 

Encapsulation  of  data 
interface  functionality 

Isolation  of  data  source 
Ick  ition 

Implementation  of 
Surrogate  internals 

3.  Complete  Executive 
Template 

Determine  overall  flow  of  control 
via  operational  model. 

Top-Level  Control  of 
Application 

Table  6-1:  Summary  of  the  Application  Development  Process 

As  described  in  the  introductory  material  to  Chapter  5,  whenever  these  steps  refer  to  the  terms 
package  specification  or  package  body,  one  can  refer  to  use  of  the  equivalent  structures  in 
other  programming  languages. 


6.1  Create  an  Application  Signatures  Package 

The  Appfication  Signatures  package  is  the  top-level  namespace  for  the  application  to  be  built. 
This  namespace  is  most  essential  to  the  executive,  but  as  (focussed  earlier,  is  needed  by 


various  package  bodies  to  complete  their  inHiementation.  This  package  is  where  the  various 
subsystems  and  surrogates  are  identified  together  as  an  Application  Aggregate.  Also,  other 
important  declarations  useful  to  the  executive  and  various  surrogates,  in  particular  the  Ul 
surrogate  (if  needed),  are  made  here. 

Three  different  kinds  of  declarations  are  made  in  this  package: 

1 .  naming  of  the  subsystems  and  surrogates  that  constitute  the  application, 

2.  naming  the  subsystem/object  callable  operations, 

3.  naming  the  statespace  for  the  application, 

6.2  Complete  Packages  Making  Use  of  Application  Signatures 

Now  that  the  application  is  defined,  via  the  namespace  and  the  underlying  references  to  the 
needed  subsystems,  the  parts  of  subsystems  and  surrogates  that  were  deferred  from  the 
processes  and  steps  listed  in  Chapter  3  can  now  be  completed.  The  completion  of  these 
packages  is  done  in  the  paragraphs  below,  performed  in  the  given  order. 

6.2.1  Complete  Surrogate  Signatures  Package 

Now  that  the  subsystems  to  be  used  are  selected,  the  surrogates  that 
provide  the  interfaces  for  data  to  be  processed  by  the  subsystems  can 
be  completely  defined. 

The  entity  namespace  is  the  list  of  identifiers  for  those  data  types 
handled  by  the  surrogate.  Simply  create  an  appropriate  enumeration 
literal  for  each  data  type  to  be  used. 

For  most  surrogates,  the  Status_Value  enumeration  type  was  previously  defined  by  the  error 
information  returned  by  the  device.  For  the  Ul  surrogate,  the  Status_Value  is  the  list  of  valid 
operations  whose  implementation  requires  the  services  of  one  or  more  subsystems.  For  each 
subsystem  with  features,  create  a  variant  record  whose  discriminant  is  based  upon  the 
subsystem's  Entity_Type,  and  then,  for  entities  whose  use  is  associated  with  a  feature,  create 
a  variant  part  with  a  field  to  hold  the  identifier  for  the  selected  feature  type.  The  Status.Type 
is  then  completed  using  the  format  given  in  the  Surrogate  Signatures  Code  template.  Also,  for 
Ul  surrogates,  the  Error_Retum_T ype  template  is  completed,  filling  in  a  variant  part  arm  for 
each  subsystem  to  include  its  Error.Type  information. 

6.2.2  Complete  Surrogate  Controller  Package  Specification 

Completion  of  the  Surrogate  Controller  code  template  (specification), 
started  in  Section  5.6,  can  now  begin.  Depending  on  whether  or  not  a 
single  Entity_Type  was  created  in  the  surrogate’s  Signatures 
package  or  the  use  of  the  subsystem  Signatures  packages  is 
required,  the  number  of  required  subprograms  can  vary  significantly. 


The  two  subprograms,  Device_T o_Application  (for  allowing  the  device  to  make  inputs  visible 
to  the  application  by  placing  value  into  the  Export  region)  and  Appiication_To_Device  (for 
sending  control  information  and  data)  are  overloaded  once  for  each  Entity_Type  from  the 
surrogate  or  subsystem  Signatures,  as  appropriate.  Again,  depending  upon  whether  or  not 
keys  are  required  (as  described  in  Section  5.6),  use  of  the  De vice_T o_ Appl ication  subprogram 
template  with  the  additional  Kind  parameter  may  be  desired. 

6.2.3  Complete  Surrogate  Import/Export  Packages 

This  process  is  equivalent  to  that  given  in  Section  5.7  for  completing 
the  subsystem  Import/Export  packages. 


6.2.4  Complete  Subsystem  Import  Package  Body 

With  the  completion  of  the  Application  Signatures  package,  the 
Import  package  body  can  be  completed  for  those  function  bodies 
that  required  the  use  of  the  Source  parameter,  as  described  in 
Section  5.7.  Additionally,  data  values  coupled  to  external  inputs  via 
the  surrogate  Export  packages  can  also  be  defined. 


6.2.5  Compete  Surrogate  Controller  Package  Body 

Completing  the  Surrogate  Controller  body  is  simply  a  matter  of 
following  through  with  the  style  of  Controller  selected  in  Section  5.8. 

The  use  of  outside  generic  packages  for  creating  the  Transform 
package(s)  to  be  the  service  providers  for  the  surrogate  controller  is 
on  an  as-needed  user-defined  basis. 

6.3  Complete  the  Executive  Template 

Finally,  the  construction  of  the  application  executive  can  begin.  A  code  template  should  be 
used  to  assist  in  the  implementation  of  the  executive,  such  as  seen  in  Appendix  E.15.  Within 
the  executive,  there  are  at  least  three  major  runtime  phases,  illustrated  by  the 
Application.State  type  in  the  Appiication_Sig natures  package.  The  initialization  phase  brings 
the  application  up  to  a  point  where  it  can  receive  inputs  and  produce  results  under  the 
specified  circumstances.  Any  operations  needed  to  initialize  the  application  must  be  called 
before  the  Program.State  is  set  to  Steady. 

Within  the  main  program  loop,  the  Ul  Signal  function  acts  as  the  driver  for  the  application,  i.e., 
the  user  selects  operations  to  be  performed  and  the  application  responds  to  those  selections. 
The  selections  are  returned  in  the  form  of  the  Status_Type  reoord  from  the  Ul  surrogate  which 
has  embedded  in  it: 
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•  the  identity  of  the  subsystem  of  primary  concern, 

•  the  operation  (translated  into  one  of  the  standard  operation  names),  and 

•  any  entity  and/or  feature  information  needed  to  control  the  subsystems  and 
underlying  objects  to  be  invoked  by  the  executive  as  a  result  of  the  selection. 

The  selection  may  invoke  a  sequence  of  operations  involving  multiple  subsystems  or 
surrogates. 

The  executive  main  loop  is  organized  internally  as  a  set  of  nested  Ada  case  statements.  By 
using  the  pieces  of  the  selection  record  in  a  consistent  way,  the  executive  can,  in  turn,  be 
organized  in  a  consistent  way  using  the  following  scheme: 

1.  The  first  level  of  decomposition  is  at  the  subsystem  level.  Even  though  multi¬ 
ple  subsystems  play  a  role  in  most  user  operations,  each  user  operation  is  rel¬ 
egated  to  a  subsystem  or  surrogate  which  has  primary  responsibility,  usually 
because  it  is  the  main  service  provider  or  the  destination  of  the  ultimate  result. 

2.  The  second  level  is  the  operation  name,  e.g.  Construct,  Destruct,  and  Fetch. 

3.  The  third  level  is  the  entity  name/identifier.  This  designates  the  type  of  data 
to  be  received,  manipulated,  and  or  returned. 

4.  The  lowest  level  is  the  feature  identifier.  As  described  in  Section  5.3,  this 
value,  if  provided,  designates  a  certain  class  of  processing  to  be  used  in 
obtaining  the  desired  result. 

Thus,  completing  the  main  body  of  the  executive  control  loop  is  a  process  of  filling  out  the  case 
statement  template  for  each  subsystem,  operation,  entity,  and  feature  selection,  as 
appropriate,  and  using  the  Operational  model  and  other  information  to  determine  the 
appropriate  sequence  of  subsystem  operations  for  each  user  selection. 

Finally,  as  in  initialization,  the  executive  can  call  a  series  of  finalization  operations  on 
subsystems  to  ensure  adequate  storage  of  important  results.  The  finalization  section  is 
reached  only  after  some  operation  has  changed  the  Program_State  of  the  executive  to  the 
Finalize  value.  After  completion  of  the  finalization  operation,  the  program  terminates  normally. 
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7  Conclusions  and  Future  Directions 


7.1  Conclusions 

The  mapping  process  described  in  this  report  provides  a  mechanism  for  using  the  information 
in  the  various  models  derived  from  exercising  the  FODA  method  on  a  domain.  The  process 
provides  for  development  of  the  specification  and  implementation  for  software  to  be  reused  in 
a  family  of  programs  within  that  domain.  The  process  is  practical  and  provides  precise 
guidance  where  applicable,  yet  is  flexible  enough  to  be  used  across  a  wide  variety  of 
application  domains. 


Figure  7-1:  A  Development  Life  Cycle  Utilizing  the  Mapping  Process 

Figure  7-1  formalizes  the  roadmap  depicted  in  Figure  1-1  at  the  beginning  of  this  report  and 
illustrates  the  use  of  the  mapping  process  as  an  integral  part  of  a  development  lifecycle  where 
domain  analysis  provides  the  models  needed  to  characterize  the  requirements  for  a  related 
set  of  applications  and  the  mapping  process  exploits  the  models  to  develop  a  generic  design 
which  is  then  reused  for  each  product  in  the  program  family. 

The  authors  completed,  with  the  assistance  of  a  graduate  student  who  wrote  the  GUI,  a 
demonstration  prototype  consisting  of  22,000  lines  of  Ada  code  and  2,500  lines  of  *C*.  This 
prototype  demonstrates  the  viability  of  the  mapping  process.  Only  a  general  notion  of  the 
desired  capabilities  were  selected  as  features  from  the  features  model.  The  remaining  data 
and  detailed  functional  requirements  were  gathered  following  this  process.  The  resulting 
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software  contains  four  subsystems,  four  objects,  two  surrogates,  two  handlers,  four 
transforms,  and  an  executive.  Of  the  22,000  lines  of  Ada,  approximately  6,500  lines  were 
reuses  of  various  Booch  components,  described  in  [Booch  87].  The  example  movement 
control  software  described  throughout  this  report  has  been  compiled  and  executed  on  multiple 
hardware/OS/compiler  combinations. 

7.2  Future  Directions 


7.2.1  Near-Term 

1.  Further  validate  the  model(s)  and  templates  by  documenting  their  usage  by 
outside  users  on  their  domain  analysis  or  reusable  software  efforts.  In  partic¬ 
ular,  work  with  an  organization  in  a  domain  with  real-time  and  other  perfor¬ 
mance  related  requirements  to  test  the  process's  ability  to  incorporate  and 
suitably  handle  such  requirements. 

2.  For  the  example  system,  further  prove  the  flexibility  of  the  OCA  by: 

a.  replacing  the  rudimentary  map  abstraction  with  calls  to  a  more 
comprehensive  Geographical  Information  System  (GIS), 

b.  reimplementing  the  “C-based  GUI  in  Ada,  using  appropriate  Ada 
bindings  to  X  and  Motif  and  removing  the  type  conversion  routines 
and  substituting  a  more  flexible  buffer  interface  for  the  data  items  to 
be  exchanged  between  the  GUI  and  the  rest  of  the  application,  and 

c.  reimplementing  the  I/O  packages  under  the  Data_Base  surrogate  to 
incorporate  the  use  of  a  commercially  available  relational  database 
using  SQL  syntax. 

3.  Extend  the  executive  model  from  its  present  form  with  a  single  thread  of 
control  to  incorporate  the  ability  to  handle  multiple  threads  of  control,  thus 
providing  the  ability  to  handle  multiple  asynchronous  devices. 

7.2.2  Long-Term 

1.  Investigate  mechanisms  that  will  make  possib'i  the  development  of  more 
highly  reusable  objects,  including  further  studies  involving  the  use  of  generics 
and  the  forthcoming  changes/features  of  the  new  Ada  standard,  Ada9X. 

2.  Investigate  the  potential  for  automation  of  the  process  of  template  generation 
and  completion  through  use  of  appropriate  software  tools.  If  this  is  successful, 
continue  to  explore  the  automation  process  towards  the  goals  of  complete 
generation  of  applications  via  selection  of  features  and  information  entities 
desired. 

3.  Further  investigate  the  processes  described  in  this  document  through  case 
studies.  From  analysis  of  such  studies,  refine  the  processes  to  strengthen 
their  utility  and  understand  their  application  in  other  domains. 

4.  Implement  the  OCA  executive  as  a  set  of  subsystems  and  surrogates  that 
provide  access  to  the  following  services: 
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a.  Event  management,  inducting  time. 

b.  Schedule  management. 

c.  Import/Export  management,  to  allow  for  the  dynamic  binding  of 
connections  between  the  Import  and  Export  packages. 

d.  Control  sequencing  (subsystem  adivation),  based  upon  schedule 
constraints  and  subsystem  location. 

e.  Registrar,  responsible  for  the  initialization,  finalization,  and  location  of 
subsystems  and  surrogates  on  an  ongoing  basis. 

Such  an  implementation  would  make  possible  fully  distributable  versions  of 
applications  using  the  OCA,  thus  achieving  the  degree  of  flexibility  needed  in 
the  design  and  implementation  of  software  systems  in  the  future. 

The  mapping  process  should  be  a  useful  addition  to  the  development  process  of  any 
organization  looking  to  reap  the  benefits  of  domain  analysis  and  the  systematic  exploitation  of 
software  architedures.  The  generic  design  and  supporting  components  developed  from  use 
of  a  domain  model  and  a  seleded  architecture  will  greatly  increase  the  reuse  potential  and 
maintainability  of  application  instances  within  a  domain  due  to  the  common  parentage  of  their 
underlying  software.  Such  increases  translate  into  decreased  long-term  costs,  an  important 
part  in  creating  a  competitive  advantage  needed  to  survive  in  today’s  global  software 
marketplace. 
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Appendix  A  The  Domain  Design  Process 

This  appendix  contains  the  detailed  descriptions  for  the  process  described  in  Chapter  4  of  this 
report.  The  details  involve  the  specifics  of  completing  the  applicable  forms  as  found  in  Appen¬ 
dix  D  using  the  designated  domain  model  information. 

A.1  Select  Features  from  Domain  Model 

No  form  data  is  completed  at  this  point. 

A.2  Create  Object  Specifications 

A.2.1  Identify  Objects 

Using  the  Object  Specification  Form  (shown  in  Appendix  D.2),  begin  the  documentation  of  the 
object  entity  by  giving  it  an  appropriate  Object  Name  and  a  short  Description  of  the  entity  to 
be  refined  in  later  steps. 

A.2.2  Derive  Object  Operations  and  Input/Outputs 

Document  the  operations  derived  from  operational  features  directly  into  the  Features  to  be 
Supported  section  of  the  Object  Specification  form  and  those  operations  needed  to  supported 
data  flows  in  the  Operational  Model  in  the  Overview  of  Requirements  section  of  the  same  form. 
For  the  inputs  and  outputs  for  each  operation  as  noted  in  the  Operational  Model,  enter  the 
information  about  them  into  the  Inputs  or  Outputs  section  of  the  Object  Specification  form  as 
appropriate.  Finally,  any  special  or  error  conditions  that  are  needed  to  describe  the  status  of 
an  object  before  or  after  an  operation  is  performed  are  noted  in  the  Exceptions/Malfunctions 
section  for  appropriate  consideration  during  further  refinement  and  implementation. 

A.3  Create  Subsystem  Specifications 

Begin  filling  out  a  Subsystem  Specification  Form  (shown  in  Appendix  D.1)  by  entering  the 
Subsystem  Name.  The  information  for  the  Description  section  can  be  taken  directly  from  the 
textual  information  in  the  features  catalog  and  the  Overview  of  Requirements  can  be  also  be 
taken  from  the  features  catalog  as  well  as  specific  wording  from  a  requirements  document.  List 
the  objects  to  be  aggregated  by  the  Subsystem  under  the  Objects  section  by  entering  those 
objects  which  are  subfeatures  of  the  parent  feature  which  is  being  allocated  as  a  subsystem. 
For  each  object,  copy  in  the  required  inputs  and  outputs  from  the  Object  Specification  Form. 

A.4  Create  Surrogate  Specifications  for  Logical  or  Physical 
Devices 

Fill  out  a  Surrogate  Specification  Form  (shown  in  Appendix  D.3).  First,  provide  a  name  in  the 
Surrogate  Name  field  and  a  Description.  Then,  enter  the  Type  information  by  selection  of  the 
control  characteristics  as  described  as  above.  The  r  section  to  I/O  device  information  is 
necessary  to  give  the  software  developer  the  req^rs  rents  to  what  kind  of  device  the 
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surrogate  is  providing  an  abstraction  tor.  For  moat  devices,  it  wiH  be  important  to  indicate  the 
device  name,  which  can  be  a  logical  device  like  X1 1  or  Motif  tor  graphical  displays  or  a 
database  product  like  Ingres  or  Informix  for  data  storage,  or  a  physical  devices,  like  a  SCSI 
controller.  For  some  devices,  it  will  also  be  necessary  to  note  the  device's  buffer  capability  in 
the  size  of  data  buffer  area.  The  device-specific  information  may  be  deferred  until  later  in  the 
surrogate’s  development.  Finally,  the  Imports  and  Exports  information  is  entered,  as 
appropriate,  in  terms  of  the  Name,  Type,  and  Source  or  Destination  and  the 
Exception/Malfunction  information  entered,  in  terms  of  Name  and  Effect. 
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Appendix  B  The  Domain  Implementation  Process 

This  appendix  contains  the  detailed  descriptions  for  the  process  described  in  Chapter  5  of  this 
report.  The  details  involve  the  specifics  of  using  the  information  on  the  specification  forms  to 
fill  out  code  templates  as  found  in  Appendix  E. 

B.1  Identify  or  Create  Applicable  System  Engineering  Units 
Package(s) 

No  specific  instructions  are  required  at  this  point. 

B.2  Create  Subsystem  _  Types  Package 

The  starting  point  is  an  Ada  _Types  package  specification  template,  seen  in  Appendix  E.2. 
The  template  provides  a  standard  placeholder  for  the  <subsystem_name>  to  be  supplied  by 
the  user.  The  given  <subsystem_name>  will  be  used  consistently  throughout  the 
succeeding  steps  that  reference  the  subsystem-level  implementation  components.  Create  the 
necessary  type  definitions,  using  the  type  information  given  on  the  Subsystem  Specification 
Form  and  its  references  to  applicable  parts  of  the  information  model. 

B.3  Create  Object  Signatures  Package 

The  Signatures  package  may  not  be  needed  at  the  object  level  if  there  are  no  appropriate 
features  to  be  dealt  with.  If  such  features  exist,  in  particular  alternative  features,  use  the  Object 
Manager  Signatures  template  as  shown  in  Appendix  E.5.  Transfer  the  Object  Name  given  on 
the  Object  Specification  Form  (completed  as  described  previously  in  Sections  4.2.1  and  4.2.2) 
onto  the  template,  replacing  the  <object_name>  placeholder.  For  each  group  of 
independent  features,  map  the  features  onto  specific  names  in  the  enumeration  list  and  give 
the  enumeration  type  itself  a  name  to  replace  the  <  feature  aroup>  placeholder. 

B.4  Create  Object  Manager  Package  Specification 

The  Object  Manager  code  template  (specification),  shown  in  Appendix  E.6,  is  the  starting  point 
for  this  step.  First,  AH  in  the  context  clause  section  by  writing  wi  th  statements  for  the  packages 
that  declare  the  types  needed  to  complete  the  parameter  profiles  for  the  subprogram 
templates.  Again,  transfer  the  Object  Name  from  the  Specification  Form  onto  the  template, 
replacing  the  <object_name>  placeholder. 

For  each  class  of  error  or  malfunction  listed  in  the  Exceptions/Malfunctions  section  of  the 
Object  Specification  Form  (or  any  otherwise  erroneous  conditions  that  potentially  may 
propagate  out  of  the  subprograms  and  into  a  controller  body),  declare  an  Ada  exception  to  be 
raised  at  applicable  points  within  the  object  body  code  and  to  be  handled  by  name  with  the 
controller  body.  Remember  to  document  the  possible  users  of  the  exception  in  the  Raised  By 
comment  immediately  after  the  exception  declaration  statement. 
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As  a  last  check,  review  the  Overview  of  Requirements  and  Features  to  be  Supported  sections 
of  the  Object  Specification  Form  and  verify  that  the  given  subprograms  in  the  completed 
Object  Manager  specification  support  all  of  the  required  operational  needs  allocated  to  the 
objects. 


B.5  Create  Subsystem/Surrogate  Signatures  Package 

B.5.1  Subsystem  Signatures 

Start  with  the  Subsystem  Signatures  code  template  as  shown  in  Appendix  E.  1 .  For  each  object 
that  is  to  become  part  of  the  subsystem  with  a  Signatures  package,  create  the  wi  th  statement 
to  gain  visibility  to  the  package  and  its  contents.  As  with  the  construction  of  the  Object 
Signatures  package,  transfer  the  Subsystem  Name  from  the  Subsystem  Specification  Form 
onto  the  template,  replacing  the  <subsystem_name>  placeholder.  The  first  major  step  in 
completing  the  Subsystem  Signatures  is  to  fill  out  the  Entity_Type  declaration  by  entering  all 
of  the  applicable  objects  and  the  entities  supported  by  them  into  the  enumeration  list.  As 
discussed  in  Section  4.2.1 ,  entities  are  all  of  those  data  items  that  must  be  manipulated  by  the 
application,  regardless  of  whether  or  not  they  are  allocated  as  actual  objects  in  the  resulting 
subsystems.  It  is  the  combination  of  these  entity  names  and  the  operation  names  that  will 
allow  the  subsystem  to  select  the  appropriate  object  operation. 

The  next  step  is  the  process  of  reexporting  the  information  contained  in  the  utilized  Object 
Signatures  packages,  if  any.  This  is  a  two  part  process: 

1.  Declare  an  Ada  subtype  using  a  feature  enumeration  type  as  the  base  type. 

For  example, 

subtype  Route_Features  is  Router . Features_Type; 

2.  For  each  enumeration  literal  declared  in  the  enumeration  base  type,  declare 
a  function  that  returns  a  value  of  the  subtype  which  renames  the  enumeration 
literal.  For  example, 

function  Best  return  Router. Features_Types 

renames  Router. Best; 

Lastly,  incorporate  the  information  found  in  the  Exceptions/Malfunctions  section  of  the 
Subsystem  Specification  Form  by  completing  the  Status_Type  declaration.  For  each  item 
listed,  create  a  corresponding  enumeration  literal  in  the  enumeration  type.  Two  of  the 
predefined  names  in  the  enumeration  list,  initialized  and  Normal  (the  first  and  last 
literals  in  the  list),  are  important  to  the  implementation  templates  and  should  not  be  removed 
or  renamed.  Note  that  the  handling  of  the  Exceptions/Malfunctions  items  differs  from  how  they 
were  used  in  development  of  the  Object  Signatures  and  Handler  specifications.  The  reasons 
for  the  differences  in  placement,  implementation,  and  ultimate  usage  will  be  discussed  in  a 
subsequent  report  describing  the  OCA  implementation  in  greater  detail. 
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B.5.2  Surrogate  Signatures 

For  surrogates,  the  process  is  similar,  but  with  a  couple  of  important  modifications.  The 
Surrogate  Signatures  code  template  is  shown  in  Appendix  E.  1 1 .  The  first  important  difference 
of  note  is  that  there  are  two  distinct  forms  of  surrogate,  one  for  user  interface  (Ul)  devices  and 
another  for  devices  not  associated  with  Uls.  The  information  content  varies  greatly  between 
the  two  forms.  The  nominal  device  surrogate  Signatures  package  contains  two  enumeration 
types: 

1.  One  lists  the  entities  (data  items)  that  are  to  be  processed  by  the  surrogate 
for  input  and  output  as  appropriate  to  or  from  the  functional  subsystems. 

2.  The  other  lists  the  errors  that  the  device  is  capable  of  generating. 

Ultimate  completion  of  the  surrogate  Signature  packages  (and  the  Controller  specification  and 
body)  must  be  deferred  until  the  application  is  defined.  However,  we  can  begin  the  process. 
In  particular,  the  basic  structure  can  be  selected  by  removal  of  inappropriate  template  items 
and  entry  of  the  package  name  can  be  done  by  replacing  the  <device_name>  placeholder 
with  the  Surrogate  Name  from  the  Surrogate  Specification  Form.  Further  work  is  deferred  until 
the  process  described  in  Section  6.2.1  begins. 

B.6  Create  Subsystem/Surrogate  Controller  Package 
Specification 

The  Subsystem  Controller  code  template  (specification)  is  shown  in  Appendix  E.3.  This  is  an 
extremely  simple  template  to  complete,  as  there  is  only  one  unique  placeholder,  that  for  the 
<subsystem_name>,  that  must  be  replaced  with  the  actual  Subsystem  name  from  the  Spec¬ 
ification  Form,  one  for  each  occurrence  of  the  placeholder  in  the  template. 

The  Surrogate  Controller  code  template  (specification)  is  shown  in  Appendix  E.12.  Just  as  was 
done  in  the  previous  section  we  can  begin  the  completion  of  the  Controller  Code  template  by 
replacing  the  <device_name>  placeholders  with  the  Name  given  on  the  Surrogate  Specifica¬ 
tion  Form. 

B.7  Create  Subsystem/Surrogate  Import  and  Export 
Packages 

The  Export  package  code  template  is  shown  in  Appendix  E.8.  The  first  step  is  to  replace  the 
occurrences  of  the  <subsystem_name>  placeholder  with  the  appropriate  Subsystem  Name. 
Remove  any  unneeded  with  statements  or  add  any  additional  references  as  determined  from 
the  Type  information  for  the  Exports  section  of  the  Specification  Form.  Then,  for  each  data 
item  listed  in  the  Exports  section,  complete  an  instance  of  the  template  for  declaring  exported 
values,  filling  out  the  <exported_value_name>  using  the  Export  Name  information  on  the 
form  and  the  applicable  data  type  and  package  information  placeholders. 
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The  Import  package  code  template  comes  in  two  parts.  The  Specification  portion  is  shown  in 
Appendix  E.9.  To  begin  filling  out  this  template,  replace  the  <device_name>  placeholder  with 
the  applicable  Subsystem  Name  from  the  Specification  Form.  Also,  fill  in  the  names  of  the 
other  subsystem  or  package  placeholders  where  data  types  to  be  imported  are  declared.  The 
use  of  the  Application_Signatures  package  is  needed  only  if  there  is  a  case  where  the  same 
data  item  (by  type  name)  can  be  imported  from  two  or  more  sources,  depending  upon  the 
current  operation  being  performed  at  the  executive  level.  Remove  this  reference  if  all  imports 
come  from  unique  sources,  as  determined  by  examination  of  the  Source  field  of  the  Imports 
section  of  the  Specification  Form.  Then,  for  each  item  listed  in  the  Imports  Name  section, 
complete  an  instance  of  the  import  function  template  using  the  Name  and  Type  information  to 
obtain  the  needed  replacement  for  placeholders. 

When  the  Import  package  specification  is  completed,  begin  the  work  of  filling  out  the  corre¬ 
sponding  Body  template,  shown  in  Appendix  E.10.  Here  is  where  the  important  task  of  binding 
data  exports  to  corresponding  imports  is  performed.  Begin  by  replacing  the  placeholders  for 
the  <subsystem_name>  and  <other_export>s  using  the  Subsystem  Name  and  the  Import 
Source  data  to  delineate  the  applicable  export  packages  to  be  withed  in  (hence,  the  neces¬ 
sity  to  declare  the  export  packages  before  the  imports).  Then,  for  each  import  function  de¬ 
clared  previously  in  the  package  specification,  create  an  equivalent  function  body  of  the 
applicable  type  corresponding  to  the  need  to  specify  a  From  source.  In  most  cases,  the  func¬ 
tion  body  will  simply  return  the  data  value  exported  by  the  data  object  in  the  Export  package. 
In  the  case  of  multiple  sources,  the  From  parameter  will  be  used  to  select  the  appropriate  arm 
of  the  case  statement  and  return  the  applicable  data  object  from  the  corresponding  Export 
package.  Again,  some  of  the  Source  export  packages  will  not  be  available  until  the  surrogates 
are  completed  later  as  described  in  Section  6.2.3  and  Appendix  C.2.3. 

B.8  Create  Subsystem/Surrogate  Controller  Package  Body 

The  Subsystem  Controller  code  template  (body)  is  shown  in  Appendix  E.4.  Begin  the 
completion  of  the  template  by  replacing  the  <subsystem_name>  placeholders  that  occur 
throughout  the  template.  Note  that  when  this  replacement  is  performed,  the  Types,  Imports, 
and  Exports  packages  are  now  correctly  named  for  use  in  the  Controller  package  body  code. 
Next,  replace  the  <object>  placeholders  with  appropriate  references  to  Objects  as  defined 
in  the  Objects  section  of  the  Subsystem  Specification  Form.  These  two  sets  of  replacements 
complete  the  context  clause  for  the  Controller  body.  The  next  step  is  to  complete  the  bodies 
for  the  operational  subprograms  using  the  sequence  of  events  information  discussed  in 
Section  5.8. 

Events  1  and  2  are  implemented  by  creation  of  an  Ada  case  statement  containing  when 
clauses  for  each  entity  to  be  handled  and  using  the  others  syntax  with  a  null  statement  or 
error  condition  to  complete  the  list  of  entity  alternatives.  Event  3  is  implemented  by  filling  in  a 
call  to  the  applicable  Object  operation  for  the  entity  to  be  handled  and  corresponding  to  the 
semantics  of  the  subsystem  call.  Event  4  requires  the  use  of  an  exception  handler  at  some 
level  within  the  procedure  body.  Depending  on  the  effect  desired,  exception  can  be  handled 


CMU/SS-94-TR-8 


within  the  block  statement  that  encapsulate  the  Object  call  with  a  specific  exception  handler, 
or  with  a  single  exception  handler  just  preceding  the  end  of  the  subprogram  being 
implemented. 

Repeat  this  step  as  needed  for  each  subprogram  stub  in  the  Controller  body.  Finally,  add  calls 
to  applicable  operations  for  any  Objects  that  require  explicit  initialization  in  the  final  statement 
block  prior  to  the  initialization  of  the  InternaLState  variable. 

The  Surrogate  Controller  code  template  (body)  is  shown  in  Appendix  E.13.  After  filling  the 
placeholders  and  creating  the  body  stubs  for  the  procedures  defined  in  the  Controller 
specification,  create  the  template  by  calling  the  operations  needed  to  handle  each  call  using 
the  Handlers  and  Transform  packages.  The  style  of  these  package  is  dependent  upon  the 
implementation  strategy  used  which  is  discussed  in  Section  5.6  of  the  report. 

B.9  Create  Object  Manager  Package  Body 

The  Object  Manager  code  template  (body)  is  shown  in  Appendix  E.7.  After  the  replacement  of 
the  <object_name>  placeholder  and  the  <subsystem_name>  placeholder  to  with  in  the 
applicable  subsystem  Types  package,  the  only  other  predefined  step  is  to  generate  a  body 
skeleton  for  each  operation  declared  in  the  Object  Manager  specification  (completed  in  Sec¬ 
tion  5.4). 
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Appendix  C  Using  a  Generic  Design  in  Application 
Development 

This  appendix  contains  the  detailed  descriptions  for  the  process  described  in  Sections  6.1  • 
6.3  of  this  report.  The  details  involve  the  specifics  of  using  the  information  on  the  specification 
forms  to  fill  out  code  templates  as  found  in  Appendix  E. 

C.1  Create  an  Application  Signatures  Package 

The  Application  Signatures  code  template  is  shown  in  Appendix  E.14.  First,  the  Application 
Aggregate  enumeration  type  definition  is  completed  by  naming  each  subsystem  and  surrogate 
to  be  used  in  the  application.  This  declaration  will  allow  the  executive  to  use  the  names  of  the 
subsystems  and  surrogates  in  its  decision  logic.  Two  subtype  declarations  provide  the 
application  with  a  single  typename  for  use  in  describing  the  subsystem  and  surrogate  subsets. 

The  next  step  is  to  define  an  enumeration  type  which  defines  the  callable  operations  to  be 
supplied  by  subsystems  and  their  underlying  objects.  The  template  gives  a  predefined  set  of 
names:  Construct ;  Destruct,  and  Fetch.  These  names  correspond  to  those  names  given  to  the 
callable  subprograms  supplied  in  the  subsystem  controller  and  object  manager  templates. 

The  last  step  is  to  define  an  enumeration  type  to  describe  an  appropriate  namespace  for  the 
overall  state  of  the  application,  i.e.,  the  executive  state.  Again,  the  template  predefines  a  useful 
three  state  system: 

1 .  Initialize  -  the  system  state  before  the  executive  invokes  any  subsystems  and 
surrogates  to  bring  the  system  to  a  defined  state  of  usability. 

2.  Steady  -  the  system  state  in  which  the  application  is  able  to  perform  its 
intended  function(s). 

3.  Finalize  -  the  system  state  in  which  the  application,  if  possible,  shuts  itself 
down  in  an  orderly  manner,  saving  system  changes  as  listed  before  final  exit. 

Other  states  may  be  added  as  necessary  for  the  executive  to  maintain  an  overall  understand¬ 
ing  of  the  state  of  the  application. 

C.2  Complete  Packages  Making  Use  of  Application 
Signatures 

C.2.1  Complete  Surrogate  Signatures  Package 

The  first  step  in  the  process  is  to  complete  the  Imports  and  Exports  sections  of  the  Surrogate 
Specification  Form  started  in  Section  4.4.  Name  all  of  the  values  exported  by  the  subsystems 
for  the  surrogate’s  use  (as  listed  in  each  subsystem’s  Exports  Destination  field)  as  Imports  with 
the  corresponding  Source.  Similarly,  name  each  value  to  be  imported  by  the  subsystems 
whose  Source  is  given  as  the  applicable  surrogate,  and  create  a  corresponding  Export  value 
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E.1 1  Surrogate  Signatures  Code  Template 


with  the  appropriate  Destination.  This  information  is  needed  to  complete  the  Signatures 
package  because  the  entities  to  be  handled  by  the  surrogate  must  be  defined  via  the 
enumeration  namespace. 

C.2.2  Complete  Surrogate  Controller  Package  Specification 

No  additional  description  for  implementation  is  needed  at  this  point. 

C.2.3  Complete  Surrogate  Import/Export  Packages 

See  Appendix  B.7  for  details  previously  described. 

C.2.4  Complete  Subsystem  Import  Package  Body 

For  each  appropriate  subsystem  that  can  supply  a  needed  data  type  for  import,  create  a  case 
arm  and  name  the  applicable  data  item  Name  from  its  Export  package.  Be  sure  to  use  the 
when  others  =>  null ;  clause  to  account  for  the  unused  subsystems. 

C.2.5  Compete  Surrogate  Controller  Package  Body 

The  Application_To_Device  and  its  converse  Device_To_Application  subprograms  are  filled 
in  using  a  format  equivalent  to  that  given  for  the  subsystem  controller  subprogram  bodies, 
where  the  entity  parameter  is  used  io  select  the  appropriate  branch/arm  of  a  case  statement 
to  invoke  the  applicable  subprograms  from  the  Transforms  and  Handlers  accessible  from  with¬ 
in  the  controller  package  body. 

C.3  Complete  the  Executive  Template 

The  Ada  code  template  to  use  as  a  starting  point  is  shown  in  Appendix  E.15.  Although  the 
construction  of  the  executive  will  involve  the  construction  of  a  significant  amount  of  code 
spanning  many  kinds  of  operations  within  an  application,  there  is  a  recurring  sequence  of 
steps  to  follow  for  each  executive  operation: 

1  If  the  operation  is  invoked  due  to  a  transfer  of  control  (i.e.,  a  Signal  return  from 
a  surrogate),  then  use  the  appropriate  Device_To_Application  as  needed  to 
transform  and  move  any  associated  data  to  the  surrogate’s  Export  package. 

2.  Determine  if  a  control  loop  exists  between  two  subsystems  and/or  surrogates 
with  respect  to  the  movement  of  multiple  data  items  between.  If  one  exists, 
determine  the  appropriate  Signal  return  value  from  a  subsystem  to  be  used 
to  terminate  the  loop. 

3.  Call  the  appropriate  sequence  of  subsystem  or  surrogate  subprograms  to 
achieve  the  desired  effect,  using  the  operational  model  as  the  basis  for 
determining  what  to  call  and  in  what  order.  The  executive  must  pass  the 
subsystem  the  appropriate  Entity,  and  possible  Feature,  information. 

4.  Ensure  any  potential  error  conditions  are  checked  for  after  subsystem 
operations  by  invoking  the  Signal  function  and  comparing  the  results  to  the 
nominally  expected  Normal  value. 
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5.  If  the  operation's  final  result  is  to  send  output  via  a  surrogate,  use  the 
appropriate  Application_To_Device  to  initiate  this  output.  Alternately,  if  a 
subsystem  generates  an  error  to  be  displayed  by  the  Ul  device,  the  Ul 
surrogate's  /pplication_To_Device  subprogram  that  uses  the 
Error_Retum_Type  must  be  invoked. 

Step  2  through  5  are  applicable  even  in  the  initialization  and  finalization  states  of  an 
application,  as  much  processing  by  subsystems  is  performed  to  upload  initial  state  from 
external  storage,  and,  conversely,  to  download  or  verify  final  state  prior  to  application 
termination. 

It  is  possible  to  segment  the  levels  of  decomposition  into  smaller  Ada  program  units,  if  desired, 
by  using  the  “separate”  facility  of  the  language  to  create  extra  subprograms  that  still  maintain 
full  visibility  of  the  executive’s  control  information,  most  importantly,  the  Status_Type  record. 
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Appendix  D  Specification  Form  Templates 

D.1  Subsystem  Specification  Form 

Subsystem  Name: _ 

Description: _ 

Overview  of  Requirements: 


Features  to  be  Supported: 


Objects: 


Imports: 

Name  Type  Source 


Exports: 

Name  Type  Destination 


Exceptions/Malfunctions. 

Name  Effect 
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D.2  Object  Specification  Form 


Object  Name: _ 

Description _ 

Overview  of  Requirements: 


Features  to  be  Supported: 


Imports: 

Name 


Exports: 

Name 


Exceptions/Malfunctions: 

Name 


Type 


Type 


Effect 
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D.3  Surrogate  Specification  Form 


Surrogate  Name: 
Description: _ 


Type:  monitor  control  (check  one  or  both) 

Connection  to  I/O  device: 

device  name _ 

size  of  data  buffer  (in  bytes) _ 

Imports  (for  monitor  surrogate): 

Name  Type  Source 


Exports  (for  control  surrogate): 

Name 


Type 


Destination 


Exceptions/Malfunctions: 

Name  Effect 


Appendix  E  Ada  Code  Templates 
E.1  Subsystem  Signatures  Code  Template 

with  <object_name>_Signatures;  --  as  BMdtd  for  Mch  object, 
package  < aubaya tem_name >_S igna tures  is 

—  avary  subsystan  controllar  has  to  differentiate  between 
--  tha  many  objacts  and  thair  parts  that  nay  ba  usad. 

—  Objacts  may  parform  oparations  differently  depending 

—  implemented  or  user- selected  features,  so  entity  names 

—  may  ba  combinations  of  entity  and  feature  identifiers. 

type  Kntity_Type  is  (  <Knt_Name_l>,  <Ent_Name_2>, 

<Ent_Name_3>  ..  <Ent_Name_n>  ); 

—  Subsystems  may  return  errors  and/or  other  Signal 

—  information.  Always  includes  a  "Normal*  or  "OK*. 

—  This  type  can  be  extended  to  incorporate  any  error 
--  conditions  to  be  propogated  to  the  executive. 

type  Status_Type  is  (  Initialized,  incomplete.  Complete, 

Invalid,  . Normal  ) ; 

type  Error_Type  is  record 
STATUS  :  Statu s_Type; 

ENTITY  s  Entity_Type; 
end  record; 


end  <subsystem_name>_Signatures; 


E.2  Subsystem  _  Types  Code  Template 

package  <subsystem_name>_Types  is 
type  <named_antity_type>  is  . . . . ; 

—  Declare  your  types  for  import  and  export  here  if  not 
—  declared  elsewhere. 

end  < aubaya taaL-,nsna>_Typea ; 
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E.3  Subsystem  Controller  Code  Template  (Specification) 

with  Application_Signatures;  --  if  Sou  res  ptnutir  used 
with  <subsystsa_name>_Signatures; 
package  <»ub«yit—Ln«— >j Control  lor  is 

—  Ivory  subsystem  controllor  hoc  at  loast  3  procoduros 
--  callable  by  the  executive,  derived  frost  these  below 
--  Optionally,  the  executive  may  require  use  of  the 
—  SOURCE  parameter  if  multiple  sources  exist  for 
—  a  particular  data  itsat. 

procedure  Construct  (  ENTITY:  in 

<subsystsa_name>_Signatures . Ent i ty_Type 
SOURCE  :  in 

Application_Signatures .  Subsystem_Type 

); 


procedure  Destruct {  ENTITY:  in 

<subsystem_name>_Signatures . Entity_Type  ) ; 

procedure  Fetch (  ENTITY:  in 

<subsystam_naate>_Signa turns . Ent ity_Type  ) ; 

—  Additionally,  each  subsystem  may  provide  to 

—  provide  control  information  to  the  executive 

function  signal  return 

<subsystem_name>_Signatures . Status_Type; 

end  <subsystem_name>_Controller; 
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E.4  Subsystem  Controller  Code  Template  (Body) 

with  SEU;  —  global  typaa 

with  <aubayatam_name>_Typea ;  --  tha  'local'  typaa 
with  <aubayat— _raaa>_Iaporta> 
with  <aubayataa_naaM>_Exporta; 

—  all  objecta  that  ara  part  of  thia  aubayatan 
with  <objectl>_Manager; 
with  <objectn>_Manager; 

packaga  body  <aubayatam_nama>_Cont roller  ia 

—  local  variablaa  daclarad  hara 

INTERNAL_STATE  :  <aubayatem_name>_Signaturea . Statua_Typa; 

procadura  Construct (  ENTITY:  in 

<aubayatam_nama>_Signaturea . EntityJType; 
SOURCE  :  in  Application_SignatureB.SubayBtam  )  ia 

bagin 

caaa  ENTITY  ia 

—  algorithm  for  chooaing  correct  Entity  Conatruct  call 
and  caaa; 
and  Conatruct; 

procedure  Deatruct(  Entity:  in 

<aubsystem_nama>_Signatures. EntityJType  )  ia 
bagin 

--  algorithm  for  chooainging  correct  Entity  Deatruct  call 
and  Da a t rue t; 

procadura  Fetch{  Entity:  in 

<aubayatem_nama>_Signaturea.Entity_Type  )  ia 
bagin 

--  algorithm  for  chooaing  correct  Entity  Patch  call,  ate. 
and  Fetch; 

function  Signal  return 

<aubayatom_nama>_SignatureB . Statua_Type  is 
Statua  :  <aubayatam_name>_Signaturea.8tatua_Type 

INTERNAL_STATE; 

begin 

INTERNAL_STATE  <8ubayatom_name>_Signature8. NORMAL; 
return  Statu a;  —  return  an  appropriate  value 
end  Signal; 

begin 

—  any  initialisation  code  goea  before  thia  atateaent 
INTERNAL_STATE  :■  <eubayatsm_nama>_Signaturea . INITIALIZED; 

end  < aubayatem_na»a>_Cont roller; 
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E.5  Object  Manager  Signatures  Template 

package  <object_name>_Signatures  is 

type  < feat urea  group >  ia  (  <£eature_l>,  <£aatura_n>  ); 

and  <objact_nama>_Signatura» ; 


E.6  Object  Manager  Code  Template  (Specification) 

with  SEU;  —  global  types 

with  <object_name>_Signatures;  —  if  uaedi 
with  . . . ;  —  other  needed  data  typea ; 
package  <6bject_nana>_Manager; 

—  The  procedurea  below  are  overloaded  as  needed  for  each 

—  parameter  profile.  Add  parameters  to  facilatate  uae  of 
--  features  in  the  Signatures  package  aa  required. 

procedure  Construct  ( 

<In_Parsmeter_l>j  in  SEU.<In_Type_l>; 

<Xn_Parameter_2> s  in  SEO  .  < In_Type_2  >  ); 

procedure  Deatruct  ( 

< In_Parameter_l > »  in  SEC . <Xn_Type_l > ; 

<In_Parameter_2>s  in  SEU.<In_Type_2>  ) ; 

procedure  Fetch  ( 

<Xn_Parameter_l>:  in  SEU. <Xn_Type_l>; 

<In_Parameter_2>:  in  SEO . <In_Type_2  > ; 

<Out_Parameter_l> :  out  SEO. <Out_Type_l> ; 
<Out_Parameter_2 > :  out  SEU . <Out_Type_2 > ) ; 

—  Export  any  error  information  as  exceptions  to 

—  calling  Subsystem  and  name  the  subprogram ( a } 

—  able  to  raise  them. 

<Error_Condition_l>  :  exception; 

—  raised  by  . . . 

<Error_Condition_n>  t  exception; 
end  <object_name>_Manager; 
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E.7  Object  Manager  Code  Template  (Body) 

with  SEU;  --  global  typas 

with  <subsystait_nama>_Typss;  —  'local'  typas 

packaga  body  <Objact>_Managar  ia 

typa  <Local_Objact>  ia  ...  ; 

—  daclaration  of  atata  data 
<Objact_Nama>  :  <Local_Objact>; 

procadura  Construct  ( 

<In_Paramatar_l> :  in  SEU.<In_Typa_l>; 
<In_Paramatar_2> :  in  SEU. <In_Typa_2  )  ia 
bagin 

—  algorithm  goas  hara 
and  Construct; 

procadura  Daatruct  ( 

< In_Paramat ar_l > :  in  SEU . < In_Typa_l > ; 
<In_Paramatar_2>t  in  SETJ. <In_Typa_2>  )  ia 
bagin 

—  algorithm  goas  hara 
and  Daatruct; 

procadura  Fateh  ( 

<Xn_Paramatar_l>s  in  SED . <In_Typa_l> ; 
<In_Paramatar_2>:  in  SEU. <In_Typa_2>; 
<Out_Paramatar_l>  s  out  BED. <Out_Typa_l> 
<Out_Paramatar_2>:  out  SEU . <Out_Typa_2 > )  ia 
bagin 

-*  algorithm  goas  hara 
and  Fateh; 

and  <Objact>_Kanagar; 


E.8  Export  Package  Code  Template 

with  SEU;  —  global  typas 

with  <subsystam_nama>_Typaa;  —  'local'  typas 

packaga  <subsystaai_xiama>_Exports  ia 

<axportad_valua_nama_l>  s  SEU.<typa_nama>; 

<axportad_valua_nama_n>  : 

<subaystam_nama>_Typas .  <typa_nama>  ; 

and  <subayataa^_nama>_Exporta; 
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E.9  Import  Package  Code  Template  (Specification) 

with  SEU;  —  global  typaa 
with  Application_Signaturea; 

with  <subsyst*m_l_name>_Types;  —  other  subsystem  types 
«  •  • 

with  <subsystem_N_name>_Types;  —  aa  needed 
package  <subsystea_nama>_Xaports  is 

function  < import 1>  return  < import l_type>; 

function  <iaport2> 

(  From  :  in  Application_Signatures .Subsystem  ) 
return  <import2_type>; 

end  <subsystam_name>_Xmports; 


E.1 0  Import  Package  Code  Template  (Body) 

with  <other_exportl>; 
with  <other_export2>; 

package  body  <subsystea_nasie>_Ifflports  is 

function  <importl>  return  < import l_type>  is 
begin 

return  <other_exportl_data>; 
end; 

function  <import2> 

(  From  :  in  Application_Signatures .Subsystem  ) 
return  < import 2_type>  is 

begin 

case  From  is 

when  <subsystam_X>  ■> 

return  <other„export2_data> ; 

end  case; 
end; 

end  <subsystem_name>_Xaports; 
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E.1 1  Surrogate  Signatures  Code  Template 

--  These  'with*'  ara  needed  only  for  01  device 
with  Application_Signatures; 
with  <aubsystam_l>_Signatures; 

with  <subsystem_n>_Signatures; 
package  <device_name>_Signatures  is 

--  Depending  upon  tha  number  of  i tarns,  tha  davica 

—  can  aithar  daclara  its  own  Entitias  or  usa  thosa  names 
--  daclarad  in  othar  Signatures  packages. 

—  Devices  may  return  errors  and/or  othar  Signal 

—  information.  Always  includes  a  'Normal"  or  "OK" . 
type  Status_Value  is  (Initialized,  ...  ,  Normal); 

—  For  tha  surrogate  to  a  Osar  Interface  davica,  the 
--  Status_Value  is  a  layer  of  records  that  provide  the 
--  Executive  with  tha  user  selected  operations/options. 

type  Status_Value(  SOBSYSTEM  : 

Application_Signatures . Subsystem_Type  )  is 
record 

Operation  : 

Application_Signatures . Operation_Type ; 
case  SOBSYSTEM  is 

when  <subsystem_l>  ■> 

<subsystem_l>_Entity  : 

<  subsystem! >_Ent i ty_Typa ; 


when  <subsystem_n>  ■> 

<subsystem_n>_Entity  s 

<subsystam_n>_Entity_Type ; 
end  case; 
end  record; 

—  Also  need  to  make  the  Error  info,  available  to  tha  OI 

type  Error_Return_Type (  SOBSYSTEM  : 

Application_Signatures.Application_Aggregate  )  is 
record 

case  SOBSYSTEM  is 

when  <subsystea_l>  ■> 

<  subsystam_l >_Error  : 

<subsystam_l >_Signatures . Error_Typa ; 


whan  <subsystam_n>  ■> 

<subsystam_n>_Error  s 

<subsystam_n>_Signaturas .Error_Type; 

end  case; 
and  record; 

and  <device_name>_Signatures; 
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E.1 2  Surrogate  Controller  Code  Template  (Specification) 

with  <device_name>_Signatures/  --  Signal  return  values 
with  <subsystem_l>_Signaturesi  —  Subsystems  to  be  handled 

e  e  e 

with  <subsystsm_n>_Signatures; 
package  <device_name>_Controller  is 

--  Send  application  data  (via  Export)  to  device 
procedure  Application_To_Device (  Entity  *  in 
<subsystem_x>_Signatures . Entity_Type  ) ; 

—  Receive  data  from  device 

procedure  Device_To_Appl i cat ion (  Entity  t  in 
<subsystem_x>_Signatures . Enti ty_Type  ) ; 

—  For  the  T7I  'device ' ,  there  is  a  notion  of  a  Key  which 

—  is  sent  in  isolation  so  that  the  application  can  Search 

—  for  a  complex  value  based  on  the  given  Key. 

type  Data_Kind  is  (  Key,  Entity  ) ; 

procedure  Device_To_Application( 

Entity  s  in  <subsystem_x>_Signatures . 

Enti ty_Type / 

Kind  :  in  Sata_Kind  ) ; 

—  Receive  status /error  information  from  device 
function  Signal  return 

<device_name>_Signatures . StatusValue ; 

end  <device_name>_Cantroller; 
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E.1 3  Surrogate  Controller  Code  Template  (Body) 

package  body  <device_nas»>_Controller  is 

procedure  Applicetion_To_Deri.ee  (  Entity  t  in 

<subsystam_x>_Signatures.Entity_Type  )  is 

begin 

—  select  proper  transform  algorithm 
end  Application_To_Device; 

procedure  Devi ce_To_Applicat ion {  Entity  t  in 

<subsystam_x>_Signatures.Entity_Type  )  is 

begin 

end  Devi ce_To_App 1 i c a t i on ; 


—  or 

procedure  Devi ce_To_App 1 i c a t i on ( 

Entity  t  in  <subsystem_x>_Signatures.Entity_Type; 
Kind  :  in  Deta_Kind  }  is 
begin 

end  Device_To_Application; 

—  Receive  statua/error  information  from  device 
function  Signal  return 

<device_name>_Signatures . Status_value  is 
begin 

return  . . . ; 
end  Signal; 
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E.14  Application.Signatures  Code  Template 

packaga  Application_Signaturea  is 

typa  Application_Aggregate  is  ( 

<aurrogate_l>,  ....  < aurroga te_n> , 

<iubiyatH_l>,  <aubayaten_2>, 

...,  <subayete*_n-l>,  <aubayataa_n>  ) ; 

aubtype  Surrogata_Type  is  Application_Aggragate 
rang*  <surrogata_l>  . .  <aurrogata_n>; 

subtypa  Subayaten_Type  ia  Application_Aggregate 
rang*  <iubiyit«a_l>  ..  <subsyatan_n>; 

--  Tha  'canon'  oparation  nawiil 

typa  Oparation  ia  (  Conatruct,  Dea tract,  Fateh  ) ; 

typa  Application_Stata  ia  {  Initializa,  Steady,  Finalize  ) 


and  Application_Signaturaa; 


E.15  Executive  Template 

with  <subsystem_l>_SigE  as; 
with  <subaystaa_n>_SigT  .^es; 
with  Application_Signatures; 

with  <subsyatem_l >_Coatroller; 
with  < aubays tem_n>_Cont rol ler j 

procedure  Executive  ia 

—  Renaming  of  all  'with'ed  packages  to  improve  readability 

package  APP  renames  Application  * J  'matures; 

Program_State  :  APP. Application, sea* '  s *  APP. INITIALIZE; 
Daer_Selection  :  xxS . Status.Type ; 

begin 

—  Call  any  needed  initialization  procedures  here! 

Program.State  APP. STEADY; 

while  Program_State  ■  APP. STEADY  loop 
Dser_Selection  >■  DIC. Signal; 
case  Dser_Selection. Subsystem  is 
when  APP.<subsystem_l>  ■> 

case  User.Selection. Operation  is 
when  APP. Construct  •> 

case  Dser_Selection.<entity_name>  is 
when  xxS. <entity_l>  ■> 

case  User  Selection. < feature  oroup>  is 
when  xxS.<feature_naaie>  ■> 

end  case; 

when  xxS - <entity_n>  ■> 

xxC .Construct (  <entity_n>  ); 

end  case; 

when  APP.Destruct  ■> 
when  APP. retch  ■> 


end  case; 
end  case; 

end  loop; 

--  Call  any  finalisation  procedure  here; 
end  Exectutive; 
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Appendix  F  Implementation  Issues  Affecting 

Reuse 

Appendix  F  discusses  some  of  the  implementation  issues  dealt  with  during  the  trial  usage  of 
these  processes,  focusing  on  Ada  language  interface  issues,  and  the  idiosyncrasies  found  in 
implementations  of  Ada  input/output  packages.  [Hefley  92]  contains  more  information  about 
other  such  issues  involved  in  the  use  of  Ada.  This  appendix  also  provides  some  specific  ex¬ 
amples  of  “C*1  code  used  in  the  user  interface  portion  of  the  movement  control  prototype  used 
as  the  example  case  in  the  report,  focused  mainly  on  the  description  of  several  reusable  ab¬ 
stractions  for  X/Motif  input  and  output. 

F.1  Interfaces  to  Other  Languages/Environments 

One  of  the  perceived  strengths  of  Ada  is  its  ability  to  interface  to  code  written  in  other 
programming  languages.  However,  this  strength  is  not  without  caveats.  First,  the  Ada 
language’s  interface  capability  is  NOT  required  to  be  supported  by  valid  Ada  rompilers2 
Second,  even  if  the  compiler  does  support  the  interface  capability,  how  the  interface  is 
implemented  is  vendor  dependent,  other  than  the  required  use  of  the  pragma  Interface.  Third, 
the  reverse  capability  of  calling  Ada  from  other  languages  is  not  defined  with  the  language.3 
None  the  less,  most  Ada  implementations  are  providing  the  interface  capability  and  many  of 
the  vendors  are  using  a  standard  (yet  still  somewhat  ad  hoc)  nomenclature  for  their  interface 
pragmas. 

F.1.1  Use  of  XII  and  Motif  with  Ada 

Access  to  Ada  bindings  for  X1 1  and  Motif  is  the  preferred  means  for  utilizing  the  powerful 
functionality  provided  by  these  pieces  of  software  for  creating  a  Graphical  User  Interface  (GUI) 
to  be  used  in  highly  interactive  applications.  Unfortunately,  not  everyone  has  access  (due  to 
cost  considerations,  chief  among  many  reasons)  to  usable  bindings  for  current,  i.e.,  widely 
used,  versions  of  XII  or  Motif.4  However,  due  to  the  interface  capabilities  described  above, 
one  can  write  a  GUI  using  X  and  Motif  calls  in  the  C  language.  There  are  two  major  issues 
involved  in  doing  this: 

1.  The  X/Motif  event  loop  must  be  able  to  respond  to  user  events  (i.e.,  mouse 
movements,  button  or  key  presses  and  releases)  in  a  thread  of  control  sepa¬ 
rate  from  that  maintained  by  the  executive  and  other  subsystems.  This  need 
requires  that  Ada's  tasking  mechanisms  be  used  to  provide  the  ability  to  han¬ 
dle  multiple  threads  of  control. 

1  The  *C*  programming  language  will  be  referred  to  hereafter  without  the  use  of  quotation  marks  for  brevity. 

*•  See  [Ada  83],  13.9(4). 

1  See  [Ada  83],  13.9(6). 

X11R5  and  Motif  vt.1  at  the  time  of  this  report 


4. 


2.  It  is  difficult,  if  not  impossible,  to  ensure  that  various  C  implementations  use 
the  same  internal  representation  for  struct s,  the  Ada  equivalent  of  records. 

The  equivalent  of  the  Ada  representation  specification  clause,  documented  in 
Section  13.4  of  [Ada  83],  is  not  available  in  C.  Even  though  most  C  compilers 
do  not  attempt  to  reorganize  streets  in  order  to  optimize  the  storage  size  or 
alignment  of  internal  fields,  there  is  no  requirement  that  they  maintain  the 
representation  given.  Thus,  there  is  no  guarantee  that  data  structures  are 
portable  across  multiple  platforms  and  compilers. 

The  net  result  is  that  there  is  no  way  to  ensure  that  data  structures  written  to 
be  transferable  across  languages  in  one  environment  will  be  reusable  in 
another  environment.  Therefore,  the  lowest  common  denominator  solution  is 
to  choose  a  single  data  type  that  can  hold,  in  theory,  information  of  any  other 
data  type  and  have  the  language  transform  important  data  structures  into  and 
out  of  me  single  data  type. 

The  common  data  type  is  the  string,  an  array  of  or  pointer  to  a  sequence  of  characters,  which 
in  C  is  logically  terminated  by  the  ASCII  NUL  value  (zero)  and  in  Ada  by  the  fixed  size  of  the 
array.  Both  languages  provide  useful  functions  that  take  numeric-based  data  and  transform  it 
into  string  equivalents  and  vice  versa.  As  long  as  the  code  in  both  languages  knows  the  order 
in  which  the  data  is  embedded  in  the  string,  each  can  maintain  record  structures  for  internal 
use,  but  also  transfer  data  between  each  other  using  the  string  as  the  common  structure. 

Section  F.3  documents  some  C/X/Motif  subprograms  that  are  reused,  in  some  cases  dozens 
of  times,  throughout  the  GUI  code  in  the  movement  control  example.5  The  Print  and 
conversion  functions  described  therein  provide  some  of  the  mechanisms  used  to  deal  with 
issues  related  to  the  use  of  strings  as  the  data  transfer  method. 


F.1.2  Calling  C  Within  Ada  and  Ada  Within  C 

To  call  Ada  code  from  C,  the  C  language  requires  tfiat  the  subprogram  be  specified  using  the 
extern  notation  to  identify  the  subprogram  whose  implementation  must  be  matched  with  the 
specification  at  link  time.  Similarly,  the  Ada  language  uses  compiler  directives  called  pragmas 
to  identify  subprograms  whose  implementation  (body)  will  be  either  supplied  by  another 
language  (importation  of  functionality),  or  whose  implementation  satisfies  the  needs  of  a 
subprogram  specified  in  another  language  (exportation  of  functionality). 

F.1.3  Ada  Tasking  in  an  Application  with  a  C/“X”-Based  GUI 

The  end  result  of  using  all  of  the  capabilities  listed  in  the  previous  sections  is  a  tasking 
architecture  for  systems  with  a  GUI  illustrated  in  Figure  F-1. 

This  figure  shows  a  design  utilizing  four  Ada  tasks.  Two  of  the  tasks,  Blocking  Input  and 
Blocking  Output,  are  passive  buffer  tasks  that  provide  a  mailbox  capability  for  data,  i.e., 
strings.  They  are  passive  in  that  they  do  not  make  any  calls,  they  are  only  called  by  their  users, 


&  Due  to  sizs  (2000+  Hn**),  the  complete  coda  for  the  GUI  is  not  included  in  Appendix  H  wham  example 
cods  is  ahown. 
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as  shown  by  the  small  control  arrows  in  the  figure.  The  Blocking  feature  is  used  to  ensure  that 
if  one  data  block  is  sent,  another  data  block  cannot  be  sent  until  the  first  has  been  received, 
i.e.,  removed  from  the  mailbox.  This  ensures  that  no  data  is  lost  and  that  data  blocks  are 
received  and  used  in  the  correct  order.  The  other  two  tasks  are  active,  the  Executive  (the  main 
program  task)  and  the  GUI.  This  Ada  task  utilizes  the  Ada  calling  C  capability  to  run  the  C  main 
procedure,  which  maintains  the  X  Event  loop  as  required.  The  C  calling  Ada  capability  is  used 
in  the  implementation  of  the  sendbuf  and  rcvbuf  routines,  which  really  are  calls  to  Ada  task 
entries  for  the  Blocking  Input  and  Output  tasks. 


Figure  F-1 :  Tasking  Architecture  Using  a  Separate  X  Event  Loop 

F.2  Using  Ada  I/O  for  Files 

Another  area  where  many  current  Ada  compilers  present  some  problems  in  the 
implementation  of  the  example  code  is  in  the  use  of  Ada  file  formats.  Some  mechanism  was 
needed  for  maintaining  some  persistent  storage  of  useful  data,  like  maps,  organized  convoys, 
vehicle  data,  etc.  in  full  implementations  of  movement  control  systems,  a  database  system, 
usually  a  relational  database,  is  the  preferred  means  for  storing  and  accessing  large  amounts 
of  interrelated  data.  Because  of  the  nature  of  the  project  and  the  complexity  of  designing  a 
suitable  database  schema,  die  example  code  uses  fHe  handling  capabilities  provided  by  the 
Ada  language.  In  particular,  a  package  called  DirecUO  provides  (in  theory)  random  access 
to  data  in  file  via  use  of  a  COUNT  value  that  produces  a  unique  key  to  provide  more  direct 
access  to  records.  Unfortunately,  at  least  one  compiler  had  problems  in  its  DirecUO 
implementation  when  Ada  variant  records  of  different  sizes  were  required  in  the  same  files. 
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One  implementation  was  unable  to  keep  track  of  a  suitable  End_Of_File  (EOF)  marker,  and 
thus,  raised  various  exceptions  when  the  EOF  was  not  found.  Therefore,  alternate 
implementations  of  some  of  the  subsystem  I/O  packages  were  required,  using  the 
Sequential  JO  package  as  the  basis  for  storing  data  and  using  additional  Text  Jo  files  to  store 
some  information  about  the  number  of  records,  etc.  that  Direct  JO  provides  intrinsically.  Even 
then,  some  compilers  require  use  of  the  implementation-dependent  file  attribute,  FORM,  to 
make  the  file  format  needed  acceptable. 

F.3  Motif/X/C  Code  Examples 

This  section  presents  some  examples  of  code  developed  for  the  initial  version  of  the  GUI  for 
the  movement  control  prototype  built  to  illustrate  the  utility  of  the  Mapping  Processes.  The 
code  and  these  descriptions  were  written  by  Mr.  Greg  Walker,  a  summer  intern  on  this  project 
in  1992. 

F.3.1  Print  Function 

The  function  mysprintf  ( )  works  a  lot  like  the  standard  C  I/O  function  sprintf  ( )  except 
that  the  result  is  written  in  a  static  buffer.  This  relieves  the  calling  routines  of  having  to  declare 
a  buffer.  The  drawbacks  are  that  subsequent  calls  to  mysprintf  { )  overwrite  the  previous 
call’s  results  and  the  buffer  >  ^s  a  fixed  size,  mysprintf  ( )  enables  code  fragments  such  as: 

char  buffer [64]/ 

sprintf (buff er, "the  answer  is  %d*,56); 
doSomethingWith( buffer) / 

to  be  rewritten  as: 

doSonethingWith(xySprintf (*the  answer  is  VS", 56))/ 

F.3.2  Converting  Strings  Between  XII  and  C 

The  function  unXmStringO  is  a  wrapper  around  XmStringGetLtoR  ( )  which  converts 
XmStrings  into  C  strings.  Each  call  to  unxmstring  ( )  frees  the  result  of  the  previous  call.  Like 
mysprintf  ( ) ,  subsequent  calls  to  unxmstring  ( )  destroy  the  results  of  previous  calls, 
unxmstring  enables  code  fragments  such  as: 

char  ‘text; 

XeStringOetlitoR ( string#  *sSTRIW3_IJ*rAt7LT_CHXRS*T ,  6 text )  ; 
dodo—  thin  gwith(  text) ; 

XtTree ( text ) j 

to  be  rewritten  as: 

doflcswthingWi  th  (unXefltrinq  ( string ) ) » 
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The  function  xmstring  ()  is  a  wrapper  around  xmStringCreateLtoR  ( )  which  converts  C 
strings  into  XmStrings  and  it  also  relieves  the  caller  from  having  to  free  the  result.  It  gets 
around  the  problem  of  subsequent  calls  destroying  the  results  of  previous  calls  by  keeping,  in 
an  array,  the  last  100  results  generated.  The  101st  call  to  xmstring  frees  the  1st  result,  the 
102nd  call  frees  the  2nd  result,  and  so  on.  This  way  fragments  such  as: 

doSooMthingWith (xmstring  ( "Hallo" ) ,  xmstring  ( "World" ) ) 

will  work  in  a  desirable  manner,  that  is,  the  2nd  call  to  xmstring  ( )  does  not  destroy  the  result 
of  the  1st  call. 

F.3.3  Routines  Utilizing  Abstractions  of  Motif  Widgets 

The  routine  feedListWidgetO  is  a  wrapper  around  XmListAddltemUns elected!) 
which  accepts  an  array  of  items  to  be  added.  Also,  it  accepts  the  items  as  C  strings  and  takes 
care  of  converting  them  to  XmStrings.  This  is  used  primarily  in  the  input()  described  below. 

The  routine  popupMessage  ( )  creates  a  message  dialog  shell/box,  displays  a  message,  and 
returns  the  users  response.  The  parent  argument  is  a  widget  to  be  used  as  the  parent  for  the 
dialog;  the  dialog  will  probably  pop  up  on  top  of  it.  The  type  specifies  the  symbol  to  be 
displayed  beside  the  message;  it  must  be  one  of  the  valid  dialogTypes  for  a  Motif 
MeSSageBox.  If  the  type  is  XmDIALOG_ERROR,  XmDIALOG_INFORMATION,  or 
xmDiALOG_MESSAGE,  the  cancel  button  will  not  be  displayed.  The  message  argument  is  a  C 
string. 

popupMessage  ( )  returns  0  if  the  user  clicks  Ok  or  -1  if  the  user  clicks  Cancel.  A  problem  with 
this  routine  is  that  in  order  to  prevent  the  user  from  doing  anything  else  with  the  application 
until  he  has  answered  the  dialog,  the  root  widget’s  sensitivity  is  set  to  False;  this  causes  some 
widgets  to  change  their  appearance. 

The  routines  popupCancelCallBacM)  and  popupErrorMessage  ( )  are  trivial  helper 
functions.  popupErrorMessage  { )  is  a  wrapper  which  sets  the  type  to  XmD ialog_error. 

The  input  ( )  function  is  a  generalized  means  for  creating  dialog  boxes  which  allow  the  user 
to  enter/edit  information.  The  dialog  boxes  can  contain  fields  of  various  types  which  are 
constructed  using  enumeration  literals  and  parameters  as  follows: 

input ( parentwidge t , 

i Label, "Hello  world.", 

iBoolean, "this  ia  a  boolean", abooleanvar table, 
iXnua,  "aero", "one", "two", "three", MULL, aintVariable, 
i  St  ring,  "Marne : " ,  fccharPointerVar  table, 
i  Int ,  "Age  *",  aintvar  table , 

irioat, "Tour  beat  eattaate  of  pi", afloatvar table, 
iMewColuma, 

t  Selection,  arrayOf  strings ,  si  zeOfArray,  acharPt  rvar , 

MOLL) i 
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Each  of  the  field  types  can  be  used  as  follows: 

•  i Label  creates  a  label  widget  displaying  the  given  string. 

•  i  Boo  lean  creates  a  togglebutton  displaying  the  given  string.  The  button’s 
state  is  initially  set  to  the  value  of  the  given  boolean  variable.  If  and  when  the 
user  clicks  Ok,  the  boolean  variable  is  updated  to  the  current  value  of  the 
toggleButton;  the  variable  is  left  unchanged  if  the  user  clicks  Cancel. 

•  iEnum  creates  a  radioBox  using  the  yiven  NULL  terminated  list  of  strings. 

The  value  of  the  intVariable  determines  which  of  the  radioButtons  is  initially 
set.  If  and  when  the  user  clicks  Ok,  the  intVariable  is  updated  to  reflect  that 
radioButton  which  is  currently  set;  if  the  user  clicks  Cancel,  the  intVariable  is 
left  unchanged. 

•  istring,  iint,  and  iFloat  will  each  create  a  textField  with  a  label  beside 
it,  allowing  the  user  to  edit  a  string/int/float.  In  the  cases  of  iint  and  iFloat, 
the  variable  will  not  be  changed  if  the  user  types  in  something  that  is  not  a 
number.  In  the  case  of  istring,  the  initial  value  of  the  variable  is  assumed 
to  be  a  malloc’ed  C  string.  If  the  user  changes  it  and  clicks  Ok,  the  old  value 
will  be  free'ed  and  space  for  the  new  value  will  be  malloc’ed. 

•  iNewCoiumn  says  that  a  new  column  should  be  created  and  subsequent 
fields  should  be  placed  in  it.  All  the  previous  fields  were  arranged  in  a  single 
vertical  column. 

•  i Selection  creates  a  scrolled  list  using  the  given  arrayOfStrings,  and  also 
creates  a  textField  which  is  managed  a  lot  like  a  textField  created  by 
istring  except  that  the  user  can  also  set  the  string  by  clicking  on  one  of  the 
items  in  the  list. 

•  The  list  of  field  declarations  must  be  null  terminated. 

input  ( )  accepts  a  variable  number  of  arguments  so  that  arbitrarily  large  dialog  boxes  may 
be  created,  input  ( )  makes  no  attempt  to  check  its  arguments  for  errors;  the  programming 
utilities  cc  and  lint  won’t  help  either. 

input  ( )  assumes  that  the  *xmList .  visibleitemCount  resource  is  set  to  a  reasonable 
value.  This  is  done  in  the  fallbackResources.  input  ( )  issues  the  same  return  values,  and 
has  the  same  problem  with  sensitivity  as  popupMessage  ( ) . 

The  routine  drawiconO  draws  a  pixmap  (icon)  whose  dimensions  are  width*height, 
centered  about  the  point  (x,  y) .  It  also  centers  the  label  underneath  the  pixmap. 
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Appendix  G 


Sample  Completed  Specification 
Forms 


G.1  Asset  Manager  Subsystem  Specification 
Subsystem  Name: 

Asset_Manager 

Description: 

Manages  the  assets  involved  in  movement  planning  (vehicles,  transportation  networks,  equip¬ 
ment). 

Overview  of  Requirements: 

Manage  information  about  military  vehicles  and  combinations  c '  vehicles. 

Source:  CMU/SEI-91-TR-28,  section  D.2.4.5. 

Features  to  be  Supported: 

Determination  of  vehicles  needed  to  facilitate  a  move  or  series  of  moves,  in  support  of  the 
planning  of  movement  operations. 

Source:  CMU/SE 1-91-  TR-28,  section  E.  1. 1.3. 

Objects: 

Vehicle 


Imports: 


Name 

Type 

Source 

Model_Or_Combo_ID 

Vehtole_Types.Model_ 

Type 

Userjnterface 

VehideJD 

Vehide_Types.Specific_ 
Vehicle Jd 

Userjnterface 

Vehicle 

Vehicle_Types.Vehide_ 

Type 

Userjnterface, 

Data_Base 

Combination 

Vehide_Types.Vehide_ 

Combination 

Data_Base 
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Name 


Type 


Destination 


Vehicle 

Vehicle_Types.Vehicle_ 

Type 

Userjnterface,  Data_Base 

Vahicie_Combination 

Vehicle_Types.  Vehicle. 
Combination 

Convoy_Builder,  Data_Base 

Exceptions/Malfunctions: 


Name 

Effect 

Asset_Manager_Signatures.lNVALID 

Fetch  of  specific  asset  information  not 
found  in  object 

G.1 .1  Vehicle  Object  Specification 


Object  Name: 

Vehicle 

Description: 

Stores  information  about  vehicles  and  combinations  of  vehicles. 

Overview  of  Requirements: 

Information  includes  vehicle  ID,  type,  width,  height,  length,  and  load-carrying  capacity. 
Source:  CMU/SEI-91-TR-28,  section  D.2.4.5.2.3. 

Features  to  be  Supported: 

Allow  the  user  to  enter,  delete,  and  find  vehicle  type  and  other  composition  data  (e.g.  height, 
width,  weight)  relevant  to  convoy  building. 

Source:  CMU/SEI-91-TR-28,  sections  E.  1. 1.3. 1. 1  and  E.  1. 1.4. 1. 1.4. 


Imports: 


Name 

Type 

Model_Or_Combo_l  D 

Vehicle_Types.Model_Type 

VehicleJD 

Vehicle_Types.Specific_Vehicle_ld 

Vehicle 

Vehicle_Types.Vehicle_T/pe 

Combination 

Vehicle_Types.Vehicle_Combination 

Exports: 


Name 

Type 

Vehicle 

Vehide_Types.Vehicle_Type 

Vehicle_Combination 

Vehide_Types.Vehicle_Combination 

Exceptions/Malfunctions: 


Name 

Effect 

Not_Found 

Fetch  of  information  relating  to  vehides  or 
combinations  abandoned  because  of 
missing  or  incorrect  data. 

G.2  Data  Base  Surrogate  Specification 


Surrogate  Name:  ' 

DataBase 

Description: 

Provides  an  interface  between  a  physical  external  data  base  and  the  other  subsystems  com¬ 
prising  the  Convoy  Planner  prototype.  This  surrogate  manages  the  creation,  deletion,  reading, 
and  updating  of  database  items.  The  prototype  implementation  uses  stored  files,  rather  than 
an  actual  database  management  system. 


Type  (check  one  or  both) 

Connection  to  I/O  Device 

Monitor 

Control 

Device  Name 

Data  Buffer  Size 
(bytes) 

Yes 

Yes 

Ada  file  I/O 

N/A 

Imports:  (for  control  surrogates) 


Name 

Type 

Vehicle 

Vehicle_Types.Vehicle_Type 

Combination 

Vehicle_Types.Vehicle_Combination 

Map_Name 

String 

Vertex 

Map_Types.Vertex_Type 

Arc 

Map_Types.Arc_Type 

Logical Jd.Value 

Natural 

Convoy_Name 

Data_Base_Types.Convoy_Element_Type 

Convoy_Parameters 

Data_Base_Types.Convoy_Parameters_ 

Type 

Exports:  (for  monitor  surrogates) 


Name 

Type 

Records_ln_File 

Natural 

ModeUd 

Vehide_Types.  ModeLType 

Vehide_ld 

Vehide_T ypes .  Specific.. Vehicle Jd 

Vehicle 

Vehide_Types.Vehtde_Type 

Name 

Type 

Combination 

Vehide_Types.Vehicle_Combination 

Convoy_Name 

String(  1 ..  DB_Types.Max_Name_Length ) 

Convoy_Part 

DB_Types.Convoy_Element_Type 

Convoy_Data 

DB_Types.Convoy_Parameters_Type 

Map_Name 

String(  1  ..  DB_Types.Max_Name_Length ) 

Vertex_Data 

Map_Types.Vertex_Type 

Arc_Data 

Map_Types.Arc_Type 

Logical_ld_Value 

Natural 

Exceptions/Malfunctions: 


Appendix  H  Movement  Control  Example  Code 

This  appendix  contains  a  large  sample  of  code  to  illustrate  the  application  of  the  processes 
described  in  this  document  using  a  FODA  domain  model  and  the  OCA  as  the  architecture.  The 
executive,  one  subsystem  (the  Asset  Manager)  with  its  objects  and  supporting  components, 
and  one  surrogate  (the  Data_Base)  with  its  Handler/IO  packages  are  listed  in  the  following 
sections. 

H.1  Executive 

with  System; 

with  Application_Signatures; 
with  User_Interface_Signatures ; 
with  Data_Base_Signatures; 
with  Mapper_Signatures ; 
with  Asset_Manager_Signatures ; 
with  Convoy_Signatures ; 
with  Convoy_Builder_Signatures ; 
with  March_Table_Signatures ; 

with  User_lnterface_Controller ; 
with  Data_Base_Controller; 
with  Mapper_Controller; 
with  Asset_Manager_Controller; 
with  Convoy_Builder_Controller; 
with  March_Table_Controller ; 

procedure  Executive  is 

—  Renamings  of  important  packages 
package  APP  renames  Application_Signa tures; 
package  UIS  renames  User_Interface_Signatures; 
package  DBS  renames  Data_Base_Signatures ; 
package  MPS  renames  Mapper_Signatures ; 
package  AMS  renames  Asset JManager_Signatures ; 
package  CS  renames  Convoy_Signa tures; 
package  CBS  renames  Convoy_Builder_Signa tures; 
package  MTS  renames  March_Table_Signa tures ; 

package  UIC  renames  User_Interface_Controller; 
package  DBC  renames  Data_Base_Controller ; 
package  MPC  renames  Mapper_Controller; 
package  AMC  renames  Asset_Manager_Controller; 
package  CBC  renames  Convoy_Builder_Controller; 
package  MTC  renames  March_Table_Controller; 

function  *=•  (  L,  R  ;  in  APP .  S  tatus_Type  }  return  Boolean 

function  *=*  (  L,  R  :  in  AMS .  Status_Type  )  return  Boolean 

function  *=*  (  l>,  R  :  in  DBS .  Status_Type  )  return  Boolean 

function  *='  (  L,  R  :  in  CBS .  Status _Type  )  return  Boolean 

function  ***  (  L,  R  :  in  MPS . Status _Type  )  return  Boolean 

function  '=*  {  L,  R  :  in  MTS .  Status_Type  )  return  Boolean 

Progrant_State  :  APP.Status_Type  APP. INITIALIZE; 


•  APP. '='  ; 
a  AMS . ' = ' ; 
a  DBS. *=* ; 
s  CBS.**'; 
a  MPS.***; 
a  MTS.***; 


User_Selection  :  UIS . Status_Type ; 


begin  -  Executive 

—  Initialisation  code  to  read  Vehicle  files  and  the  Convoy  and  Map  fiats. 
DBC.Application_To_Devi.ce  (  ENTITY  =>  DBS  . MODEL_LIST , 

STATUS  =>  Program_State  ) ; 

UIC . Application_To_Device (  DBS . MODEL_ID  ); 

loop 

DBC.Device_To_Application{  DBS. MODEL  ); 

•nit  when  DBC. Signal  =  DBS . END_OF_FILE ; 

DBC . Device_To_Appl ication (  DBS . MODEL_ID  ) ; 

AMC. Construct (  ENTITY  =>  AMS. MODEL, 

SURROGATE  =>  APP . DATA_BASE  ) ; 
UIC.Application_To_Device(  DBS.MODEL_ID  ); 
end  loop; 

DBC.Application_To_Device(  ENTITY  =>  DBS.VEHICLE_LIST, 

STATUS  =>  Program_State  ) ; 
UIC.Application_To_Device(  DBS . VEHICLE_ID  ); 

loop 

DBC . Devi ce_To_Appl ication (  DBS . SPECIFIC_VEHICLE  ) ; 
exit  when  DBC. Signal  =  DBS . END_OF_FILE; 

DBC . Device_To_Application (  DBS . VEHICLE_ID  ) ; 

—  AMC. Construct (  ENTITY  =>  AMS.SPECIFIC_VEHICLE, 

SURROGATE  =>  APP . DATA_BASE  ); 

UIC . Application_To_Device (  DBS . VEHICLE_ID  ); 
end  loop; 

DBC .Application_To_Device (  ENTITY  =>  DBS . COMBINATION_LIST , 

STATUS  =>  Program_State  ) ; 
UIC.Application_To_Device(  DBS . COMBINATION^ D  ); 

loop 

DBC . Device_To_Appl ication (  DBS .VEHICLE_COMBINATION  ); 
exit  when  DBC. Signal  =  DBS . END_OF_FILE; 

DBC . Device_To_Appl ication (  DBS . COMBINATION_ID  ) ; 

—  AMC -Construct (  ENTITY  =>  AMS . VEHICLE_COMBINATION , 
SURROGATE  =>  APP . DATA_BASE  ); 
UIC.Application_To_Device (  DBS . COMBINATION_ID  ); 
end  loop; 

DBC.Application_To_Device(  ENTITY  *=>  DBS.MAP_LIST, 

STATUS  =>  Program_State  ) ; 

UIC . Application_To_Device (  DBS .MAP_NAME  ); 

loop 

DBC . Device_To_jAppl ication (  DBS. MAP _NAME  ); 
exit  when  DBC . Signal  =  DBS . END_OF_FILE ; 
UIC.Application_To_Device{  DBS.MAPJNAME  ); 

end  loop; 

DBC . Application_To_Device (  ENTITY  =>  DBS ,CONVOY_LIST, 

STATUS  *>  Program_State  ) ; 
UIC.Application_To_Device(  DBS . CONVOY_NAME  ) ; 

loop 

DBC . Device_To_Appl ication (  DBS . CONVOY_NAME  ); 

•nit  when  DBC. Signal  «  DBS . BND_OF  _FILE; 

UIC . Application_To_Device (  DBS . CONVOY_NAME  ); 

end  loop; 
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-  Initialisation  complete,  give  the  user  CONTROL! 

Program^  tate  : =  APP. STEADY; 

while  Program_State  =  APP. STEADY  loop 

User_Selection  :=  UIC. Signal; 
case  User.Selection . SUBSYSTEM  ia 
when  APP . USER^INTERFACE  => 

ease  User.Selection. OPERATION  ia 
when  APP . DESTRUCT  => 

Program_State  :=  APP.  FINALIZE;  -  This  is  QUIT!!!!!! 

when  othera  =>  null; 

end  case; 

when  APP . DATA_BASE  => 

caae  User .Selection. OPERATION  ia 
when  APP. CONSTRUCT  =>  null; 

when  APP. DESTRUCT  => 

caae  User.Selection . DATA_BASE_ENTITY  ia 
whan  DBS. MAP  => 

UIC.Device_.To Application;  DBS .MAP_NAME  ); 
DBC.Application_To_Device(  DBS . MAP.NAME  ); 

whan  DBS. CONVOY  => 

UIC.Device_To_Application(  DBS . CONVOY.NAME  ); 
DBC.Application_To_Device(  DBS . CONVOY_NAME  ); 

when  othera  =>  null; 

end  case; 

whan  APP. FETCH  => 

caaa  User.Selection . DATA_BASE_ENTITY  ia 
whan  DBS. MAP  => 

MPC . Destruct (  MPS . MAP  ) ; 

UIC . Device.To .Application (  DBS . MAPNAME  ); 
DBC.Application_To_Device(  ENTITY  =>  DBS. MAP, 

STATUS  =>  APP. INITIALIZE  ); 

if  DBC. SIGNAL  =  DBS. NORMAL  than 

DBC . Device_To_APPlication (  DBS. VERTEX  ); 
UIC.Application_To_Device(  DBS. VERTEX  ); 

loop 

DBC .Device_To_Application (  DBS. VERTEX  ); 
exit  whan  DBC. Signal  =  DBS . END_OF_FILE ; 

UIC . Application_To_Device (  DBS. VERTEX  ); 
MPC. Construct (  ENTITY  =>  MPS. VERTEX, 

SOURCE  =>  APP . DATA.BASE  ); 

end  loop; 

DBC . Device_To_Application (  DBS. ARC  ); 

UIC . Application_To_Device (  DBS .ARC  ); 

loop 

DBC.Device_To^Application(  DBS. ARC  ); 
exit  whan  DBC. Signal  =  DBS . END_OF_FILE; 

UIC . Application_To_Device (  DBS . ARC  ) ; 

MPC. Construct (  ENTITY  *>  MPS. ARC, 

SOURCE  *>  APP . DATA.BASE  ); 


DBC.Device_To_Application(  DBS . LOGICAL_ID  .  ; 
UIC.Application_To_Device(  DBS . LOGICAL_ID  ); 
DBC.Application_To_Device(  ENTITY  =>  DBS. MAP, 
STATUS  =>  APP. FINALIZE  ); 

(In 

UIC.Application_To_Device(  (  SUBSYSTEM  => 

APP . DATA_BASE , 

DATA_BAS E_ERROR  => 

{  ENTITY  =>  DBS. MAP, 

STATUS  =>  DBS . NOT_FOUND  )  )  ); 

•ad  if; 

vhu  DBS. CONVOY  => 

CBC . Destruct (  CBS . Convoy  ) ; 

UIC . Device_To_Appl ication (  DBS . CONVOY_NAME  ) ; 
DBC.Application_To_Device(  ENTITY  =>  DBS. CONVOY, 
STATUS  =>  APP. INITIALIZE  ); 
DBC.Device_To_Application(  DBS. ELEMENT  ); 
UIC.Application_To_Device(  DBS. ELEMENT  ); 
loop 

DBC.Device_To_Application(  DBS. ELEMENT  ); 

•xit  whan  DBC. Signal  =  DBS . END_OF_FILE; 

UIC . Application_To_Device (  DBS. ELEMENT  ); 

CBC. Construct (  CBS . CONVOY_PART  ); 

•ad  loop; 

DBC . Device_To_Appl ication (  DBS . PARAMETERS  ) ; 

CBC .  Construct  (  CBS  .  CONVOY_PARAMETERS  )  ; 

DBC . Application_To_Device (  ENTITY  =>  DBS. CONVOY, 
STATUS  =>  APP. FINALIZE  ); 

whan  othars  =>  null; 

•ad  caaa,- 
and  caaa; 

whan  APP . CONVOY_BUILDER  => 

caaa  user_Selection. OPERATION  is 
whan  APP. CONSTRUCT  => 

caaa  User_Selection . CONVOY_BUILDER_ENTITY . ENTITY  is 
whan  CBS. SUBUNIT  => 

UIC . Device_To_Appl ication (  CBS. SUBUNIT  ); 

CBC. Construct (  CBS. SUBUNIT  ); 

whan  CBS. VEHICLE  => 

UIC . Device_To^Application (  CBS. VEHICLE  ); 
caaa  User_Selection.CONVOY_BUILDER_ENTITY.  IMPORT 

whan  AMS. MODEL  => 

AMC. Fetch (  ENTITY  =>  AMS. MODEL, 

AS_TYPE  => 

AMS  .VEHICLE_C COMBINATION  ); 

whan  AMS . SPECIPIC_VEHICLE  => 

AMC . Patch (  ENTITY  *>  AMS . SPECIFIC_VEHICLE, 
AS_TYPE  => 

AMS  .VEHICLE-COMBINATION)  ; 

Whan  AMS .  VEHICLE-COMBINATION  *> 
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AMC . Fetch (  AMS . VEH ICLE.COMBINATION  ) ; 


when  others  =>  null; 

end  ease; 

CBC . Construct (  CBS .VEHICLE  ) ; 
when  CBS. SPEED  => 

UIC.Device_To_Application(  CBS. SPEED  ); 

CBC. Construct (  CBS. SPEED  ); 

when  CBS. GAP_DI STANCE  => 

UIC .Device_To_Application(  CBS .GAP_DISTANCE  ); 

CBC. Construct (  CBS .GAP_D I STANCE  }; 

When  CBS. GAP_DI STANCES  => 

UIC . Device_TO_Application (CBS . GAP.DI STANCES) ; 

CBC. Construct (  CBS .GAP_DISTANCES  ); 

When  CBS . GAP_MULTIPLIER  => 

UIC . Device_To_Application (CBS . GAP_MULTI PLI ER ) ; 

CBC . Construct (  CBS . GAP_MULTIPLIER  ) ; 

When  CBS . GAP_MULTI PLIERS  => 

UIC . Device_To_Application (CBS . GAP_MULTI PLIERS ) ; 

CBC . Construct (  CBS . GAP_MULTIPLIERS  ) ; 

when  CBS. CONVOY  => 

case  User_Selection.CONVOY_BUILDER_ENTITY  .FEATURE 

arisen  CS. FIXED  => 

CBC . Construct (  CBS . FIXED  ) ; 
when  CS. GOVERNED  => 

CBC . Construct (  CBS . GOVERNED  ) ; 

end  case; 

when  others  =>  null ; 

end  case; 

when  APP . DESTRUCT  => 

case  User .Selection. CONVOY_BUILDER_ENTITY. ENTITY  is 
when  CBS. SUBUNIT  => 

UIC . Device_To_Application (  CBS. SUBUNIT  ); 
CBC.Destruct(  CBS. SUBUNIT  ); 

when  CBS. VEHICLE  => 

UIC . Device_To_Application (  CBS. VEHICLE  ); 

CBC. Des true t (  CBS. VEHICLE  ); 

when  CBS . CONVOY  => 

CBC . Destruct (  CBS. CONVOY  ); 

DBC.^>plication_To_Device(  ENTITY  =>  DBS. CONVOY, 

STATUS  =>  APP . FINALIZE  ) ; 

when  others  =>  nail; 
end  case; 

when  APP. FETCH  => 

ease  User .Selection . CONVOY_BUILDER.ENTITY . ENTITY  is 
when  CBS . GAP .KIND  «> 


CBC. Fetch (  CBS.GAP_KIND  ); 

UIC . Application_To_Device (  CBS . GAP_KIND  ) ; 

when  CBS . SPEED  => 

CBC. Fetch (  CBS. SPEED  ); 
UIC.Application_To_Device(  CBS. SPEED  ); 

When  CBS. GAP_DI STANCE  => 

CBC. Fetch (  CBS. GAP_DI STANCE  ) ; 
UIC.Application_To_Device(  CBS .GAP_DISTANCE  ); 

When  CBS. GAP_DI STANCES  => 

CBC . Fetch (  CBS . GAP_DI STANCES  ) ; 

UIC . Application_To_Device (  CBS . GAP_DISTANCES ) ; 

when  CBS . GAP_MULTIPLIER  => 

CBC. Fetch (  CBS . GAP_MULTIPLIER  ); 

UIC . Application_To_Device (CBS . GAP_MULTIPLIER) ; 

Whan  CBS. GAP_MULTI PLIERS  => 

CBC. Fetch (  CBS . GAP_MULT I PLIERS  ); 

UIC . Application_To_Device (CBS . GAP_MULTIPLIERS ) ; 

whan  CBS. CONVOY  => 

UIC . Device_To_Appl ication (  DBS . CONVOY_NAME  ) ; 
DBC.Application_To_Device(  ENTITY  =>  DBS. CONVOY, 
STATUS  =>  APP. STEADY  ); 

loop 

CBC. Fetch (  CBS . CONVOY_PART  ); 

DBC . Application_To_Device (  DBS. ELEMENT  ) ; 
exit  whan  CBC. Signal  =  CBS. complete,- 

and  loop; 

CBC. Fetch (  CBS . CONVOY_PARAMETERS  ); 
DBC.Application_To_Device(  DBS .PARAMETERS  ); 
DBC.Application_To_Device(  ENTITY  =>  DBS. CONVOY, 
STATUS  =>  APP. FINALIZE  ); 


whan  othara  =>  null; 

and  caaa; 
and  case; 

whan  APP . AS S ET_MANAGER  => 

casa  User_Selection. OPERATION  ia 
whan  APP. CONSTRUCT  *> 

eaaa  User_Selection.ASSET_MANAGER_ENTITY  la 
whan  AMS. MODEL  => 

UIC . Device_To_Application (  AMS. MODEL  ); 

AMC. Construct (  ENTITY  =>  AMS. MODEL, 

SURROGATE  =>  APP . USER_INTERFACE  ); 
DBC . Application_To_Device (  DBS. MODEL  ); 

whan  othara  =>  null; 

and  eaaa; 


whan  APP . DESTRUCT  => 

eaaa  User_Selection. ASSET  JMANAGER_ENTITY  la 
whan  AMS. MODEL  => 

UIC . Device_To_JApplication (  ENTITY  *>  AMS. MODEL, 
KIND  =*>  UIC. KEY  )  ; 
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AMC . Des  truct (  AMS . MODEL  ) ; 
DBC.Application_To_Device(  DBS.MODEL_ID  ); 

whan  othars  =>  null; 

•ad  cut; 

«h«n  APB. FETCH  => 

case  User_Selection.ASSET_MANAGER_ENTITY  is 
whan  AMS. MODEL  => 

UIC.Device_To_Application(  ENTITY  =>  AMS. MODEL, 

KIND  =>  UIC.KEY  ); 

AMC. Fetch {  AMS. MODEL  ); 

UIC .Application_To_Device (  AMS. MODEL  ); 

whan  othars  =>  null; 

and  cssa; 

•ad  eaam; 

whan  APP. MAPPER  => 

css*  User_Selection. OPERATION  is 
•ban  APP . CONSTRUCT  => 

css*  User_Selection.MAPPER_ENTITY. ENTITY  is 
whan  MPS. VERTEX  => 

UIC . Devi c e_To_Appl ication(  MPS. VERTEX  ) ; 

MPC. Construct (  ENTITY  =>  MPS. VERTEX, 

SOURCE  =>  APP . USER_ INTERFACE  ); 

whan  MPS. ARC  => 

UIC . Device_To_Application (  MPS. ARC  ); 

MPC. Construct!  ENTITY  =>  MPS. ARC, 

SOURCE  =>  APP . USER_INTERFACE  ) ; 

whan  MPS. CONSTRAINTS  => 

CBC . Fetch {  CBS. CONSTRAINTS  ); 

MPC . Construct (  MPS . CONSTRAINTS  ) ; 

MPC . Fetch {  MPS. CONSTRAINTS  ); 
UlC.Application_To_Device{  MPS. ROUTE  ); 

whan  othars  =>  anil; 

•ad  cssa; 

whan  APP . DESTRUCT  => 

cssa  Us  er_Se 1 ec  t i on . MAPPER^ENTITY . ENTITY  is 
whan  MPS. VERTEX  => 

UIC . Device_To_Application (  ENTITY  =>  MPS. VERTEX, 

KIND  =>  UIC.KEY  ); 
MPC.Destruct (  MPS. VERTEX  ); 

whan  MPS. ARC  => 

UIC.Device_To_Application(  HTTITY  =>  MPS. ARC, 

KIND  =>  UIC.KEY  ); 
MPC.Destruct!  MPS. ARC  ); 

whan  MPS. CONSTRAINTS  => 

MPC.Destruct!  MPS . CONSTRAINTS  ); 

whan  MPS. MAP  *> 

MPC . Des truct (  MPS . Map  ) ; 

DBC . Application_To_Device (  ENTITY  =>  DBS. MAP, 


STATUS  =>  APP. FINALIZE  ); 


when  others  =>  null; 

•nd  ct*« ; 

when  APP. FETCH  => 

esse  User_Selection.MAPPER_ENTITY. ENTITY  is 
when  MPS.ARC  => 

UIC.Device_To_Application(  ENTITY  =>  MPS.ARC, 
KIND  =>  UIC.KEY  ); 

MPC. Fetch (  MPS.ARC  ); 

UIC .Application_To_Device (  MPS.ARC  ); 

when  MPS. ROUTE  => 

UIC ,Device_To_Application(  MPS. ROUTE  ); 

CBC. Fetch (  CBS . CONSTRAINTS  ); 
esse  User_Selection .MAPPER_ ENTITY . FEATURE  is 
when  MPS. BEST  => 

MPC. Fetch (  MPS. BEST  ); 
when  MPS . SATISFICE  => 
null; 
end  esse; 

UIC.Application_To_Devi.ce  (  MPS.  Route  ); 
when  MPS. MAP  => 

UIC.Device_To_Application(  DBS . MAP_NAME  ) ; 
DBC.Application_To_Device(  ENTITY  =>  DBS. MAP, 
STATUS  =>  APP . STEADY  ) ; 

MPC . Cons  true  t (  MPS . VERTICES  ) ; 

loop 

MPC. Fetch (  MPS. VERTICES  ); 

exit  when  MPC. Signal  =  MPS. COMPLETE; 

DBC.Application_To_Device(  DBS. VERTEX  ); 

end  loop; 

MPC. Construct {  MPS. ARCS  ); 

loop 

MPC. Fetch (  MPS. ARCS  ); 

exit  when  MPC. Signal  =  MPS. COMPLETE; 

DBC.Application_To_Device(  DBS. ARC  ); 

end  loop; 

UIC . Device_TO_Application (  DBS . LOGICAL_ID  ); 
DBC.Application_To_Device(  DBS . LOGICAL_ID  ); 
DBC.Application_To_Device(  ENTITY  =>  DBS. MAP, 
STATUS  =>  APP. FINALIZE  ); 


when  others  =>  null; 
end  case; 
end  ease; 


when  APP . MARCH_TABLE  => 

ease  User_Selection. OPERATION  is 
when  APP. CONSTRUCT  =>  null; 

when  APP . DESTRUCT  =>  null; 

when  APP. FETCH  => 
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case  User_Selection.MARCH_TABLE_ENTITY.  ENTITY  is 
whan  MTS . MARCH_TABLE  => 

UIC.Device_To_Application(  MTS . MARCH_T ABLE  ); 
CBC. Fetch (  CBS. LENGTH  ); 

CBC . Fetch (  CBS . SPEED  ) ; 

MTC . Destruct (  MTS . MARCH_TABLE  ) ; 

CAS*  User_Selection.MARCH_TABLE_ENTITY.  FEATURE 

whan  MTS. FORWARD  => 

MTC . Construct (  ENTITY  =>  MTS . MARCH_TABLE , 
FEATURE  =>  MTS . FORWARD  ) ; 

whan  MTS. BACKWARD  => 

MTC. Construct (  ENTITY  =>  MTS . MARCH_TABLE , 
F'SATURE  =>  MTS .  BACKWARD  )  ; 


and  casa; 

if  MTC. Signal  =  MTS. NORMAL  than 
MTC . Fetch (  MTS . MARCH_TABLE  ) ; 

UIC . Application_To_Device (MTS . MARCH..TABLE ) ; 

alsa 

UIC . Application_To_Device ( 

(  SUBSYSTEM  =>  APP . MARCH_TABLE , 
MARCH_TABLE_ERROR  => 

(  ENTITY  =>  MTS . MARC H_TABLE , 
STATUS  =>  MTS . INVALID  )  )  ) ; 

and  if; 


whan  othars  =>  null; 
and  casa; 
and  case; 
and  casa; 

and  loop; 


-  Finalization  code  to  close  some  List  files  opened  during  initialization. 


DBC .  Application_To. 
DBC .  Application_To. 
DBC .Application_To. 
DBC . Application_To. 
DBC . Application_To. 
and  Executive; 


.Device (  ENTITY  => 
STATUS  => 
.Device (  ENTITY  => 
STATUS  => 
Device (  ENTITY  => 
STATUS  => 
.Device  (  ENTITY  => 
STATUS  => 
.Device  (  ENTITY  •=> 
STATUS  => 


DBS . MODEL_LIST , 
Prograxn_State  )  ; 

DBS . VEHICLE_LI ST . 
Program_State  ) ; 

DBS . COMBINATION_LIST , 
Program_State  ) ; 
DBS.MAPJLIST, 
Progrrara_State  )  ; 

DBS . CONVOY_LIST, 
Program_State  ) ; 
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H.2  Applicatlon_Signatures 

package  Application_Signatures  la 


type  Application_Aggregate  la  (  USER_INTERFACE,  DATA_BASE, 
CONVOY_BUILDER,  MARCH_TABLE ,  MAPPER,  ASSET_MANAGER  ) ; 

aubtypa  Surrogate_Type  la  Application_Aggregate 
range  US ER_INTERFACE  ..  DATA_BASE ; 

aubtypa  Subsystem_Type  la  Application_Aggregate 
range  CONVOY_BUILDER  . .  AS S ET_MANAGER ; 

type  Status_Type  la  (  INITIALIZE,  STEADY,  FINALIZE  ) ; 

type  Operation_Type  la  (  CONSTRUCT,  DESTRUCT,  FETCH  ) ; 

and  Application_Signa tures ; 
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H.3 


Asset  Manager  Subsystem 


f 


H.3.1  Asset  Manager  Controller  (Specification) 

with  Application_Signatures; 
with  Asset_Manager_Signatures ; 
package  Asset_Manager_Contr oiler  ia 

package  AMS  renames  Asset_’lanager_Signatures ; 
package  APP  renames  Application_Signatures; 


procedure  Construct {  ENTITY  :  in  AMS . Entity_Type ; 

SURROGATE  :  in  APP . Surrogate_Type  ) ; 

procedure  Destruct{  ENTITY  :  in  AMS . Entity_Type  ); 

procedure  Fetch (  ENTITY  :  in  AMS . Entity_Type  ); 

procedure  Fetch (  ENTITY  :  in  AMS.Entity_Type; 

AS_TYPE  :  in  AMS . Entity_Type  ); 

function  Signal  return  AMS.Status_Type; 

end  Asset_Manager_Controller; 
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H.3.2  Asset  Manager  Controller  (Body) 


with  Asset_Manager_Impor ts ; 
with  Asset_Manager_Exports; 
with  Vehicle_Types ; 
with  VehicleJManager; 
with  Default; 

package  body  Asset_Manager_Controller  ia 

--  renaming  declaration  for  package  abbreviations 

package  AMI  renames  Asset_Manager_lmports ; 
package  AME  renames  Asset_Manager_Exports; 
package  VM  renames  Vehicle_Manager; 
package  VT  renames  Vehicle_Types; 

use  Asset_Manager_Signatures ; 


local  variables  and  subprograms  declared  here 
INTERNAL_STATE  ;  AMS . StatUS_Type; 

End  declarations  and  code  for  internal  subprograms 


Begin  code  for  subprograms  declared  in  package  specification 

procedure  Construct (  ENTITY  ;  in  AMS . Ent i ty_Type ; 

SURROGATE  :  in  APP . Surrogate_Type  )  is 

begin 

case  ENTITY  is 
when  MODEL  => 

VM. Construct {  MODEL_OR_VEH I CLE  =>  AMI. Vehicle (  SURROGATE  ), 
KIND_OF_VEHICLE  =>  VT. GENERAL  ) ; 

AME. Vehicle  :=  AMI. Vehicle (  SURROGATE  ); 

when  SPECIFIC_VEHICLE  => 

VM. Construct (  MODEL_ORw_VEHICLE  =>  AMI. Vehicle (  SURROGATE  ), 
KIND_OF_VEHICLE  =>  VT. SPECIFIC  ); 

AME. Vehicle  :=  AMI .Vehicle (  SURROGATE  ); 

When  VEHICLE_COMBINATION  => 

VM. Construct {  AMI .Combination (  SURROGATE  )  ); 
AME.Vehicle_Combination  :=  AMI .Combination (  SURROGATE  ); 


when  others  =>  null; 
end  case; 

L  Construct; 


procedure  Destruct(  ENTITY  :  ia  AMS . Entity_Type  )  is 

begin 

case  ENTITY  is 
when  MODEL  => 

VM . Destruct (  AMI .Model_Or_Combo_ID  ) ; 


whan  MODELS  => 

VM. Destruct (  VT. General  ); 

when  SPECIFIC_VEHICLE  => 

VM. Destruct (  AMI .Vehicle_lD  ); 

when  VEHICLES  => 

VM.Destruct(  VT. Specific  ); 

when  VEHICLE_COMBINATION  => 

VM.  Destruct  (  AMI  .Mode l_Or_Coinbo_ID  ); 

when  COMBINATIONS  => 

VM. Destruct ; 

end  case; 

end  Destruct; 


procedure  Fetch (  ENTITY  :  in  AMS . Enti ty_Type  )  is 
Done  :  Boolean; 

begin 

ceee  ENTITY  is 
when  MODEL  => 

VM. Fetch (  MODEL_ID  =>  AMI  .Model_Or_Cornbo_ID, 
MODEL  =>  AME. Vehicle  ) ; 


when  MODELS  => 

VM. Fetch (  KIND  =>  VT. GENERAL, 

VEHICLE  =>  AME. Vehicle, 

LAST  =>  Done  ) ; 

if  Done  then 

INTERNAL_STATE  ;=  COMPLETE; 

else 

INTERNAL_STATE  :=  INCOMPLETE; 

end  if; 

whan  SPECIFIC_VEHICLE  => 

VM. Fetch (  VEHICLE_ID  =>  AMI . Vehicle_ID, 
VEHICLE  =>  AME. Vehicle  ) ; 


when  VEHICLES  => 

VM. Fetch (  KIND  =>  VT. SPECIFIC, 

VEHICLE  =>  AME. Vehicle, 
LAST  =>  Done  ) ; 
if  Done  then 

INTERNAL_ STATE  :=  COMPLETE ; 

else 

INTERNAL_STATE  :=  INCOMPLETE ; 

end  if; 


VEHICLE_COMBINATION  *> 

VM. Fetch (  COMBINATION_ID  =>  AMI  .Model_Or__Combo_ID 
COMBINATION  =>  AME. Vehicle_Combination 

COMBINATIONS  => 

VM. Fetch (  COMBINATION  =>  AME . Vehicle_Corabination, 
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LAST  =>  Done  ) ; 

if  Done  then 

INTERNAL-STATE  :=  COMPLETE; 

elae 

INTERNAL-STATE  :=  INCOMPLETE 

end  if; 


when  others  =>  null; 
end  case; 

end  Fetch; 


procedure  Fetch (  ENTITY  :  in  AMS.Entity_Type; 

AS_TYPE  :  in  AMS . Ent i ty_Type  )  is 
Temp_ Vehicle  :  VT. Vehicle— Type; 

Temp_Config  :  VT. Configured— Vehicle; 

Temp_Combo  :  VT.Vehicle_ Combination (  VT. Single  ); 
begin 

case  ENTITY  is 
when  MODEL  => 

case  AS_TYPE  is 

when  VEHICLE_COMBINATION  => 

VM . Fetch (  MODEL_ID  =>  AMI .Model_Or_Coinbo_ID, 
MODEL  =>  Temp_Vehicle  ) ; 
Temp_Combo. Total  :=  Temp_Vehicle . Properties ; 
Temp_Config. Vehicle  :=  Temp_Vehicle; 
Temp_Combo . Prime  :=  Temp_Conf ig; 
AME.Vehicle_Combination  :=  Temp_Combo; 

when  others  =>  INTERNAL_STATE  :=  INVALID; 

end  case; 

when  SPECIFIC-VEHICLE  => 
case  AS_TYPE  is 

when  VEHICLE_COMBINATION  => 

VM. Fetch (  MODEL-ID  =>  AMI . Mode l_Or_C ombo_I D , 
MODEL  =>  Temp-Vehicle  )  ; 

Temp— Combo . Total  : =  Temp_Vehi c 1 e . Properties ; 
Temp-Config. Vehicle  :=  TempJ Vehicle; 
Temp_Coinbo . Prime  :=  Tenp_ Config; 

AME. Vehicle-Combination  :=  Temp_Combo; 

when  others  =>  INTERNAL-STATE  :=  INVALID; 

end  case; 


when  others  =>  INTERNAL-STATE  :=  INVALID; 

end  case; 

l  Fetch; 


function  Signal  return  AMS . Status-Type  is 

Status  :  AMS. Status-Type  :=  INTERNAL-STATE 

begin 

INTERNAL-STATE  :*  NORMAL; 
return  Status; 
end  Signal; 


H.3.3  Asset  Manager  Signatures 


package  Asset_Manager_Signatures  is 

type  Entity_Type  is  (  MODEL,  MODELS.  SPECIFIC_VEHICLE.  VEHICLES, 

VEHICLE_COMBINATION,  COMBINATIONS  ) ; 

typs  StatUS_Type  is  (INITIALIZED,  INCOMPLETE,  COMPLETE,  INVALID,  NORMAL); 

type  Error_Type  is  rscord 
STATUS  :  Status_Type; 

ENTITY  ;  Entity_Type; 

•ad  record; 

snd  Asset_Manager_Signatures ; 


H.3.4  Asset  Manager  Imports  (Specification) 


with  VehicIe_Types ; 

with  Application_Signatures; 

package  Asset_Manager_Imports  is 

package  APP  renames  Application_Signatures  ; 
package  VT  renames  Vehicle_Types; 

function  Model_Or_Combo_ID  return  VT . Model^Type ; 

function  Vehicle_ID  return  VT. Specif ic_Vehicle_Id; 

function  Vehicle (  SOURCE  :  in  APP . Surrogate_Type  ) 

return  VT.Vehicle_Type; 

function  Combination (  SOURCE  :  in  APP . Surrogate_Type  ) 

return  VT.Vehicle_Combination; 


end  AssetJManager_lmports ; 
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H.3.5  Asset  Manager  Imports  (Body) 


with  User_Interface_Exports; 

with  Data_Base_Exports ; 

packtgt  body  Asset_Manager_Imports  is 

package  UIE  rani— ■  User_Interface_Exports; 
package  DBE  ran— ■  Data_Base_Exports; 

function  Model_Or_Combo_ID  raturn  VT . Model_Type  is 

begin 

raturn  UIE.Model_ID; 
aad  Model_Or_Combo_ID; 

function  Vehicle_ID  raturn  VT. Specif ic_Vehicle_Id  is 

bagin 

raturn  UIE. Specif ic_Vehicle_Id; 
and  Vehicle_ID; 

function  Vehicle (  SOURCE  :  in  APP . Surrogate_Type  ) 

raturn  VT.Vehicle_Type  is 

bagin 

csaa  SOURCE  is 

whan  APP . USER_INTERFACE  => 
raturn  UIE. Vehicle; 

wban  APP . DATA_BASE  => 
raturn  DBE. Vehicle; 

and  easa; 

and  Vehicle; 

function  Combination (  SOURCE  :  in  APP . Surrogate_Type  ) 

raturn  VT.Vehicle_Combination  is 

begin 

csaa  SOURCE  is 

Wban  APP . USER_INTERFACE  => 
raise  Program_Error ; 

—  raturn  UIE. Combination ; 
whan  APP . DATA_BASE  => 

raturn  DBE. Combination ; 
and  casa; 

1  "  and  Combination; 

t 

and  Asset_Manager_Imports ; 

I  ! 

H.3.6  Asset  Manager  Exports 


■  * 


H.3.7  Vehicle  Manager  (Specification) 

with  Vehicle_Types; 
ptckaga  Vehicle_Manager  is 

package  VT  rnaasi  Vehicle_Types; 


procedure  Construct (  MODEL_OR_VEHICLE  :  in  VT.Vehicle_Type; 

KIND_OF_VEHICLE  :  la  VT.Vehicle_State  ) ; 

procadura  Construct (  COMBINATION  :  la  VT.Vehicle_Combination  ); 


procadura  Destruct (  MODEL_OR_COMBO_ID  :  la  VT . Model_Type  ) ; 
procadura  Destruct (  VEHICLE_WITH_ID  :  la  VT. Specif ic_Vehicle_ID  ) ; 

procadura  Destruct (  KIND  :  la  VT.Vehicle_State  ); 

—  Destroys  entire  contents  of  list  specified  by  Kind 

procadura  Destruct; 

—  Destroys  entire  contents  of  Combinations  data 


procadura  Fetch (  MODEL_ID  :  la  VT.Model_Type; 

MODEL  :  out  VT . Vehicle_Type  ) ; 

procadura  Fetch (  VEHICLE_ID  :  la  VT. Specif ic_Vehicle_ID; 

VEHICLE  :  out  VT . Vehicl e_Type  ) ; 

procadura  Fetch (  COMBINATION_ID  :  la  VT.Model_Type; 

COMBINATION  :  out  VT.Vehicle_Combination  ) ; 

procadura  Fetch (  KIND  :  la  VT.Vehicle_State; 

VEHICLE  :  out  VT. Vehicle_Type; 

LAST  :  out  Boolean  ) ; 

procadura  Fetch(  COMBINATION  :  out  VT.Vehicle_Combination; 

LAST  :  out  Boolean  ) ; 

Not_Found  :  except  ion;  —  raised  if  Fetch  with  an  ID  finds  No  Match 
and  Vehicle_Hanager; 
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H.3.8  Vehicle  Manager  (Body) 

with  Ring_Sequential_Unbounded_Managed_I terator ; 
with  Default; 

package  body  Vehicle_Manager  ia 

package  Vehicle_Storage  la  new  Ring_Sequential_Unbounded_Managed_I terator 

(  ITEM  =>  VT.Vehicle_Type  ) ; 

package  Combo_Storage  la  new  Ring_Sequential_Unbounded_Managed_I terator 

(  ITEM  =>  VT.Vehicle_Combination  ); 

function  *  =  * (  L,  R  :  in  VT.Model_Type  )  return  Boolean  renames  VT . *  =  * ; 
function  *  =  '  (  L,  R  ;  in  VT.Vehicle_State  )  return  Boolean  renames  VT . '  =  * 
function  *=* {  L,  R  :  in  VT. Specif ic_Vehicle_Id  )  return  Boolean 

renames  VT . * = * ; 

_ it************************************************************.********,,*** 

—  local  variables  and  subprograms  declared  here 

Models  :  Vehicle_Storage . Ring ; 

Vehicles  :  Vehicle_Storage.Ring; 

Combinations  :  Combo_Storage . Ring ; 


Fetch_Active  :  Boolean  :=False; 

- ********************************************************************* 

procedure  Find_Model{  MODEL_ID  ;  in  VT.Model_Type; 

FOUND  :  out  Boolean  )  ia 

begin 

FOUND  :=  False; 

Vehicle_Storage.Mark(  Models  ); 

loop 

if  Vehicle_Storage.Top_Of {  Models  ) .Properties. Model  =  MODEL_ID 

then 

Vehicle_Storage.Mark(  Models  ); 

FOUND  :=  True; 

else 

Vehicle_Storage. Rotate (  The_Ring  =>  Models, 

In_The_Direction  =>  Vehicle_Storage. Forward  ); 

end  if; 

exit  when  Vehicle_Storage.At_Mark{  Models  ); 

end  loop; 

end  Find_Model  ; 

..A******************************************************************** 

procedure  Find_Vehicle (  VEMICLE_ID  :  in  VT. Specif ic_Vehicle_Id; 

FOUND  :  out  Boolean  )  ia 

begin 

FOUND  : *  False; 

Vehi c 1 e_S torage . Mark {  Vehicles  ); 

loop 

if  Vehicle_Storage .Top_Of (  Vehicles  ) .Vehicle_ld  =  VEHICLR_ID  then 
Vehicle_Storage .Mark (  Vehicles  ); 

FOUND  ;*  True; 


Vehicle_Storage. Rotate!  The_Ring  =>  Vehicles, 

In_The_Direction  =>  Vehicle_Storage. Forward  ) 

end  if; 

exit  when  Vehicle_Storage.At_Mark (  Vehicles  ); 

end  loop; 

l  FindJ Vehicle; 


procedure  Find_Combo(  COMBO_ID  :  in  VT.Model_Type; 

FOUND  :  out  Boolean  )  is 

begin 

FOUND  :=  False; 

Combo_Storage.Mark (  Combinations  ); 

loop 

if  Combo_Storage .Top_Of (  Combinations  ) .Total .Model  =  COMBO_ID  then 
Combo_Storage.Mark(  Combinations  ); 

FOUND  :=  True; 

else 

Combo_Storage. Rotate!  The_Ring  =>  Combinations, 

In_The_Direction  =>  Combo_Storage .Forward  ); 

end  if; 

exit  when  Combo_Storage .At_Mark (  Combinations  ); 

end  loop; 

end  Find_Combo; 

End  declarations  and  code  for  internal  subprograms 


—  Begin  code  for  subprograms  declared  in  package  specification 

procedure  Construct!  MODEL_OR_VEHICLE  :  in  VT. Vehicle_Type; 

KIND_OF_VEHICI,E  :  in  VT. Vehicle_State  )  ie 
01d_Value  :  Boolean  :=  False; 

begin 

cnee  kind_of_vehicle  is 

when  VT. GENERAL  => 

if  not  Vehicle_Storage.Is_Erapty(  Models  )  then  —  look  for  OLD 


version 


FindJModel (  MODEL_ID  =>  MODEL_OR_VEHICLE . Properties .Model , 
FOUND  =>  01d_Value  ) ; 

if  01d_Value  then  --  Remove  OLD  version  before  Inserting  NEW 
Vehicle_Storage.Rotate_To_Mark(  Models  ); 
Vehicle_Storage.Pop(  Models  ); 

end  if; 
end  if; 

Vehicle_Storage. Insert!  The_Item  =>  MODEL_OR_ VEHICLE , 

In_The_Ring  =>  Models  ) ; 

when  VT. SPECIFIC  => 

if  not  Vehicle_Storage .  Is_Enq?ty  (  Vehicles  )  then  —  look  for  OLD 

Find_Vehicle (  VEHICLE_ID  =>  1©DEL_0R_  VEHICLE . Vehicle_Id, 
FOUND  =>  OldLValue  ); 

if  01d_Value  then  —  Remove  OLD  version  before  Inserting  NEW 
Vehicle_Storage . Rotate_To_Mark (  Vehicles  ); 
Vehicle_Storage . Pop (  Vehicles  ); 

end  if; 


•ad  if; 

Vehicle_Storage . Insert (  The_Item  =>  MODEL_OR_ VEHICLE, 

In_The_Ring  =>  Vehicles  ) ; 


•ad  case; 

•ad  Construct ; 


procedure  Construct (  COMBINATION  :  in  VT.Vehicle_Combination  )  is 
01d_Value  :  Boolean  :=  False; 

begin 

if  not  Combo_Storage. Is_Enpty(  Combinations  )  then  —  look  for  OLD 
version 

Find_Combo(  COMBO_ID  =>  COMBINATION. Total .Model, 

FOUND  =>  Old_Value  ) ; 

if  01d_Value  then  —  Remove  OLD  version  before  Inserting  NEW 
Combo_Storage.Rotate_To_Mark(  Combinations  ); 

Combo_Storage . Pop (  Combinations  ); 

end  if; 
end  if; 

Combo_Storage. Insert (  The_Item  =>  COMBINATION, 

In_The_Ring  =>  Combinations  ) ; 

end  Construct; 


procedure  Destruct (  MODEL_OR_COMBO__I D  :  in  VT.Model_Type  )  is 
Id_Found  :  Boolean  :=  False; 

begin 

if  MODEL_OR_COMBO_ID (  9  )  =  '  '  then  —  This  is  a  MODEL 
Find_Model (  MODEL_ID  =>  MODEL_OR_COMBO_ID , 

FOUND  =>  Id_Found  ) ; 
if  Id_Found  then  --  Remove 

Vehicle_Storage . Rotate_To_Mark (  Models  ); 

Vehicle_Storage.Pop(  Models  ); 
end  if; 

else  —  This  MUST  be  a  COMBINATION 

Find_Combo (  CCMBO_ID  =>  MODEL_OR_COMBO_ID , 

FOUND  =>  Id_Found  ) ; 
if  Id_Found  then  —  Remove 

Combo_Storage . Rotate_To_Mark (  Combinations  ) ; 

Combo_Storage . Pop (  Combinations  ); 
end  if; 

•ad  if; 
end  Destruct; 

- ************************************************************************* 


procedure  Destruct {  VEHICLE_WITH_ID  :  in  VT. Specif ic_Vehicle_ID  )  is 


Id^Found  :  Boolean  : =  False; 

begin 

Find-Vehicle (  VEHICLE-ID  =>  VEHICLE_WITH_ID, 
FOUND  =>  Id_Found  ) ; 
if  Id-Found  then  —  Remove 

Vehicle_Storage .Rotate_To  _Mark(  vehicles  ); 
Vehicle-Storage . Pop (  Vehicles  ); 
end  if; 

•ad  Destruct; 
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procedure  Destruct (  KIND  :  in  VT.Vehicle_State  )  in 

boffin 

ease  KIND  is 

whan  VT. GENERAL  => 

Vehi c 1 e_S tor age . C 1 ear {  Models  ) ; 
whoa  VT. SPECIFIC  => 

Vehicle_Storage .Clear (  Vehicles  ); 
end  case; 
end  Destruct; 

_ ************************************************************************* 

procedure  Destruct  is 

begin 

Combo_Storage. Clear (  Combinations  ); 
and  Destruct; 

_ ************************************************************************* 

procedure  Fetch (  MODEL_ID  :  in  VT . Model_Type ; 

MODEL  :  out  VT . Vehi c 1 e_Type  )  is 
Id_Found  :  Boolean  :=  False; 

boffin 

if  not  Vehicle_Storage.Is_Eirpty(  Models  )  then 
FindLModel (  MODEL_ID  =>  MODEL_ID, 

FOUND  =>  Id_Found  ) ; 
if  Id_Found  than 

Vehicle_Storage . Rotate_To_Mark (  Models  ); 

MODEL  :=  Vehicle_Storage .Top_Of (  Models  ); 

else 

MODEL  :=  Default .General_Vehicle; 

MODEL. Properties. Model  :=  MODEL_ID; 

end  if; 

else 

MODEL  :=  Default. General_Vehicle; 

MODEL. Properties. Model  :=  MODEL_ID; 

end  if; 

end  Fetch; 

_ ************************************************************************* 

procedure  Fetch{  VEHICLE_ID  :  in  VT. Specif ic_Vehicle_ID; 

VEHICLE  :  out  VT. Vehicle_Type  )  is 
Id_Found  :  Boolean  :=  False; 

boffin 

if  not  Vehicle_Storage.Is_Empty(  Vehicles  )  then 
Find_Vehicle (  VEHICLE_ID  =>  VEHICLE_ID, 

FOUND  =>  Id_Found  ) ; 
if  Id_Found  then 

Vehicle_Storage.Rotate_To_Mark(  Vehicles  ); 

VEHICLE  :=  Vehicle_Storage.Top_Of (  Vehicles  ); 

else 

raise  Not_Found ; 

end  if; 

else 

raise  Not_Found ; 
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•ad  if; 

•ad  Fetch; 


procedure  Fetch {  COMBINATION_ID  :  ia  VT.Model_Type; 

COMBINATION  :  out  VT . Vehicle_Combination  )  is 
Id_Found  :  Boolean  :=  False ; 

begin 

if  not  Combo_Storage . Is_Empty (  Combinations  )  than 
Find_Combo(  COMBO_ID  =>  COMBINATION_ID, 

FOUND  =>  I d_ Found  ) ; 

if  Id_Found  than  --  Remove  OLD  version  before  Inserting  NEW 
Combo_Storage.Rotate_To_Mark(  Combinations  ); 

COMBINATION  ;=  Combo_Storage .Top_Of (  Combinations  ); 

•Isa 

raise  Not_Found; 

and  if; 

•Isa 

raise  Not_Found; 

and  if; 

and  Fetch; 


procadura  Fetch (  KIND  :  in  VT . Vehicle_State ; 

VEHICLE  :  out  VT . Vehi cl e_Type ; 

LAST  :  out  Boolean  )  is 

begin 

case  KIND  is 

when  VT. GENERAL  => 

if  not  Fetch_Active  than 

if  Vehicle_Storage.Is_Empty (  Models  )  than 
raise  Not_Found; 
and  if; 

Vehicle_Storage  .Mark(  Models  );  —  This  will  be  the  LAST  one 
e! 

Fetch_Active  :=  True; 

and  if; 

Vehicle_Storage . Rotate!  The_Ring  =>  Models, 

In_The_Di recti on  =>  Vehicle_Storage. Forward  ) ; 
VEHICLE  :=  Vehicle_Storage . Top_Of (  Models  ); 
if  Vehicle_Storage.At_Mark(  Models  )  than  —  At  the  LAST  one? 
FetciL_Active  :=  False; 

LAST  : =  True ; 

•Isa 

LAST  :=  False; 

and  if; 


whan  VT. SPECIFIC  => 

if  not  Fetch _Active  than 

if  Vehicle_Storage . Is_Empty (  Vehicles  )  than 
raise  Not_Found; 

and  if; 

Vehicle_Storage .Mark(  Vehicles  ); 

Fetch_Active  :=  True; 

and  if; 

Vehicle_Storage . Rotate (  The_Ring  =>  Vehicles, 

In_The_Direction  =>  Vehicle_Storage . Forward  ); 
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VEHICLE  :=  Vehicle_Storage . Top_Of (  Vehicles  ); 
if  Vehicle_Storage .At_Mark{  Vehicles  )  then 
Fetch_Active  =  False; 

LAST  :=  True; 

•Is* 

LAST  :=  False; 

•nd  if; 

•nd  cue; 

•ad  Fetch; 


procedure  Fetch (  COMBINATION  :  out  VT.Vehicle_Combination; 

LAST  :  out  Boolean  )  is 

begin 

if  not  Fetch_Active  then 

if  Combo_Storage .  Is_Ernpty  (  Combinations  )  then 
raise  Not_Found; 

•nd  if; 

Combo_Storage .Mark {  Combinations  ) ; 

Fetch_Active  :=  True; 

•nd  if; 

Combo_S torage. Rotate (  The_Ring  =>  Combinations, 

In_The_Direction  =>  Combo_Storage . Forward  ); 
COMBINATION  :=  Combo_Storage .Top_Of (  Combinations  ); 
if  Combo_Storage . At_Mark (  Combinations  )  then 
Fetch_Active  :=  False; 

LAST  : =  True ; 
else 

LAST  :=  False; 

•nd  if; 

•nd  Fetch; 


•nd  Vehicle_Manager; 
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H.4  Data  Base  Surrogate 


H.4.1  Data  Base  Controller  (Specification) 

with  Data_Base_Signatures; 
with  Application_Signatures; 
packaga  Data_Base_Controller  is 

packaga  APP  rsniwss  Application_Signatures; 
packaga  DBS  ranaaas  Data_Base_Signatures; 


procadura  Device_To_Application(  ENTITY  :  in  DBS.Entity_Type  ); 

procadura  Application_To_Device (  ENTITY  :  in  DBS .Entity_Type; 

STATUS  :  in  APP . StatUS_Type 
: =  APP . STEADY  ) ; 


function  Signal  raturn  DBS.Status_Type; 
and  Data_Base_Controller; 
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H.4.2  Data  Base  Controller  (Body) 

with  Vehicle_Types; 
with  Data_Base_ Imports ; 
with  Data_Base_Exports ; 
with  DB_Vehicle_IO; 
with  DB_Convoy_IO; 
with  DB_Map_IO; 

package  body  Data_Base_Controller  ia 

package  DBE  rename ■  Data_Base_Exports ; 
package  DBI  rename a  Data_Base_Imports ; 

—  local  variables  and  subprograms  declared  here 

S I GNAL_STATE  :  DBS . Status_Type ; 

Count_Read  :  Boolean  :=  False; 

--  End  declarations  and  code  for  internal  subprograms 


*************************************************************************** 
—  Begin  code  for  subprograms  declared  in  package  specification 


procedure  Device_To_Application(  ENTITY  :  in  DBS.Entity_Type  )  ia 

begin 

caae  ENTITY  ia 

when  DBS . MAP_NAME  => 

begin 

DB_Map_IO . Get_Map_From_List (  DBE . Map_Name  ); 

exception 

when  DB_Map_IO . End_Of _Fi 1 e  => 

SIGNAL_STATE  :=  DBS . END_OF_FILE; 

end; 


when  DBS. VERTEX  => 

begin 

if  not  Count_Read  then 

DBE.Records_In_File  : =  DB_Map_IO . Number_Of _Vertices ; 
Count_Read  : =  True; 

elae 

DB_Map_IO . Get (  DBE . Vertex_Data  ); 

end  if; 
exception 

when  DB _Map_IO . End_Of_File  => 

SIGNAL_STATE  :=  DBS . END_OF_FILE; 

Count_Read  : =  False; 

end; 

whan  DBS. ARC  => 

begin 

if  not  Count_Read  then 

DBE . Records_In_File  ;=  DB_Map_IO . Number_Of_Arcs ; 
Count_Read  : =  True; 

else 

DB_Map_IO . Get (  DBE.Arc_Data  ); 

end  if; 
exception 

when  DB_>lap_IO .  End_Of _Fi  le  => 


Count.Read  :=  False; 

•ad; 


when  DBS . LOGICAL_ID  => 

DB_Map_IO.Get(  DBE.Logical_Id_Value  ); 

when  DBS. MODEL  => 

begin 

DB_Vehicle_IO.Get_Model (  DBE. Vehicle  ); 

exception 

when  DB_Vehicle_IO.End_Of_File  => 

SIGNAL.STATE  :=  DBS . END.OF.FILE; 

end; 

when  DBS . MODEL_ID  => 

DBE.Model_Id  :=  DBE .Vehicle . Properties .Model ; 

when  DBS . SPECIFIC_VEHICLE  => 

begin 

DB_Vehicle_10.Get_Vehicle(  DBE. Vehicle  ); 

exception 

when  DB_Vehicle_IO.End_Of_File  => 

SIGNAL.STATE  :=  DBS . END.OF.FILE; 

end; 

when  DBS . VEHICLE_ID  => 

DBE . Model_Id  :=  DBE. Vehicle. Properties. Model; 
DBE.Vehicle_Id  :=  DBE. Vehicle. Vehicle.ld; 

when  DBS . VEHICLE.COMBINATION  => 

begin 

DB_Vehicle_IO.Get_Combination(  DBE. Combination  ); 

exception 

when  DB_Vehicle_IO.End_Of.File  => 

SIGNAL.STATE  :=  DBS . END.OF.FILE ; 

end; 


when  DBS . COMBINATION_ID  => 

DBE.Model_Id  :=  DBE. Combination. Total. Model; 

when  DBS . CONVOY_NAME  => 

begin 

DB_Convoy_IO . Ge  t_C onvoy_Fr om_L i s t (  DBE . Convoy_Name  ) ; 

exception 

when  DB_Convoy_IO . End_Of_File  => 

SIGNAL. STATE  :=  DBS . END_OF_FILE; 

end; 


when  DBS . ELEMENT  => 

begin 

if  not  Count_Read  then 

DBE.Records_In_File  :=  DB_Convoy_IO . Number.Of .Elements ; 
Count_Read  ;=  True; 

else 

DB.Convoy.IO . Get (  DBE . Convoy.Part  ); 

end  if; 
exception 


Count_Read  : =  False; 

•ad; 


when  DBS . PARAMETERS  => 

DB_Convoy_IO . Get (  DBE . Convoy_Data  ) ; 

whan  others  =>  null; 

•ad  mm; 

•ad  Device_To  ication; 


procedure  Application_To_Device{  ENTITY  :  in  DBS.Entity_Type; 

STATUS  :  in  APP . Status_Type 
:=  APP. STEADY  )  is 

begin 

case  ENTITY  is 


when  DBS . MAP_LI ST  => 
case  STATUS  is 

•ben  APP. INITIALIZE  => 

DB_Map_IO . Open_Li s t_F i 1 e ; 

DBE .Records_In_File  : =  DB_Map_IO . Number_Of _Maps ; 


when  APP. STEADY  =>  null; 


when  APP. FINALIZE  => 

DB_Map_IO .Close_List_File; 

end  case; 


when  DBS. HAP  => 
case  STATUS  is 

when  APP. INITIALIZE  => 

begin 

DB_Map_lO.Open_Map_Files{  Name  =>  DBI . Map_Name , 

Mode  =>  DB_Map_IO . Input  ) ; 

exception 

when  DB_Map_IO. Invalid_Map_Name  => 

SIGNAL_STATE  :=  DBS .NOT_FOUND; 

•ad; 


when  APP. STEADY  => 

DB_Map_IO . Open_Map_Files (  Name  =>  DBI . Map_Name , 

Mode  =>  DB_Map_IO . Output  ) ; 
DB_Map_IO . Put_Map_In_List (  DBI .MapjName  ); 

whan  APP. FINALIZE  => 

DB_Map_IO . Close _Map_Files ; 

•ad  case; 

When  DBS . MAP _NAME  => 

DB_Map_IO . Delete_Map_Files (  DBI .Map_Name  ); 

DB_Map_IO .Remove_Map_From_Li8t (  DBI . Map_Name  ); 

whan  DBS. VERTEX  => 

DB_Nap_IO . Put (  DBI . Get_Vertex  ); 

when  DBS. ARC  «> 

DB_Map_IO . Put (  DBI . Get_Arc  ) ; 

When  DBS.LOOICALu.ID  «> 
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DB_Map_IO . Put (  DBI . Logical_Id_Value  ) ; 

whan  DBS . MODEL_LIST  => 
casa  STATUS  is 

Whan  APP. INITIALIZE  => 

DB_Vehicle_IO . Open_Models_File ; 

DBE.Records_In_File  :=  DB_Vehicle_IO.Number_Of_Models; 

whan  APP. STEADY  =>  null; 

whan  APP. FINALIZE  => 

DB_Vehicle_IO . Close_Models_File ; 

and  csss; 

whan  DBS. MODEL  => 

DB_Vehicl e_IO . Put_Model (  DBI . Get_Vehicle  ) ; 
whan  DBS . MQDEL_ID  => 

DB_Vehicle_IO.Remove_Model (  DBI .Get_Vehicle  ); 

whan  DBS . VEHICLE_LIST  => 
casa  STATUS  is 

whan  APP. INITIALIZE  => 

DB_Vehicle_IO . Open_Vehi c 1 e s_F i 1 e ; 

DBE.Records_In_File  := 

DB_Vehicle_IO ,Number_Of_Vehicles ; 

whan  APP. STEADY  =>  null; 

whan  APP. FINALIZE  => 

DB_Vehi c 1 e_IO . C 1 os e_Vehi c 1 e s_F i 1 e ; 

and  casa; 

whan  DBS . SPECIFIC_VEHICLE  => 

DB_Vehicle_IO.Put_Vehicle(  DBI .Get_Vehicle  ); 

Whan  DBS . VEHICLE_ID  => 

DB_Vehicle_IO.Remove_Vehicle(  DBI .Get_Vehicle  ); 

Whan  DBS . COMBINATION_LIST  => 
casa  STATUS  is 

whan  APP. INITIALIZE  => 

DB_Vehicle_IO . Open_Combinations_File ; 
DBE.Records_In_File  ;= 

DB_Vehicle_IO  .Number_Of  Combinations ; 

whan  APP. STEADY  =>  null; 

whan  APP. FINALIZE  => 

DB_Vehicle_IO .  Close_Coinbiiiations_File  ; 

and  casa; 

Whan  DBS . VEHICLE_COMBINATION  => 

DB_Vehicla_IO.Put_Combination(  DBI.Get_Coinbination  ); 

whan  dbs . combination_id  => 

DB_Vehicla_IO . Remove_Combination (  DBI . Get_Combination  ) ; 
whan  DBS. CONVOY  JLIST  » 
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Casa  STATUS  i* 

whan  APP. INITIALIZE  => 

DB_Convoy_IO . Open_Lis  t_Fi le ; 

DBE . Records_In_File  : =  DB_Convoy_IO . Number _Of_Convoys ; 

when  APP. STEADY  =>  null; 

iriMB  APP. FINALIZE  => 

DB_Convoy_IO . Close_List_File ; 

•ad  cum; 

whan  DBS. CONVOY  => 
caaa  STATUS  Is 

whan  APP. INITIALIZE  => 

DB_Convoy_IO . Open_Convoy_Files (  DBI . Convoy_Name , 

DB_Convoy_IO . Input  ) ; 


tdun  APP.  STEADY  => 

DB_Convoy_IO . Open_Convoy_Fi les (  DBI . Convoy_Name , 

DB_Convoy_IO . Output  ) ; 

DB_Convoy_IO . Put_Convoy_In_List (  DBI . Convoy_Name  ); 

whan  APP. FINALIZE  => 

DB_Convoy_IO .Close_Convoy_Files ; 

and  caaa; 

whan  DBS .  CONVOY_NAME  => 

DB_Convoy_IO.Delete_Convoy_Files (  DBI . Convoy_Name  ); 
DB_Convoy_IO.Remove_Convoy_From_List (  DBI . Convoy_Name  ); 

whan  DBS. ELEMENT  => 

DB_Convoy_IO . Put (  DBI . Get_Convoy_Part  ) ; 
whan  DBS . PARAMETERS  => 

DB_Convoy_IO . Put (  DBI .Get_Convoy_Parameters  ); 

and  caaa; 

and  Application_To_Device; 


function  Signal  return  DBS.Status_Type  ia 
Status  :  DBS . Status_Type  :=  SIGNAL_STATE ; 

begin 

S I GNAL_ STATE  : =  DBS. NORMAL;  —  RESET  upon  READ! 
return  Status; 

•ad  Signal; 


SIGHAL_STATE  s*  DBS. INITIALIZED ; 
•ad  Da ta_Baaa_Cont roller ; 


f 


H.4.3  Data  Base  Signatures 


package  Data_Base_Signatures  is 

type  Entity_Type  is  (  MAP_LIST,  MAP,  MAP_NAME,  VERTEX,  ARC,  LOGICAL_ID, 

MODEL_LIST,  MODEL,  MODEL_ID,  VEHICLE_LIST, 
SPECIFIC_VEHICLE,  VEHICLE_ID,  COMBINATION_LIST, 
VEHICLE_COMBINATION,  COMBINATION_ID,  CONVOY_LIST, 
CONVOY,  CONVOY_NAME,  ELEMENT,  PARAMETERS  )  ,- 

type  Status_Type  is  (  INITIALIZED,  NOT_FOUND,  END_OF_F I LE ,  NORMAL  ) ; 

typa  Error_Type  is  record 
STATUS  :  Status_Type ; 

ENTITY  :  Entity_Type ; 

*  t  record ; 

and  •  i_Base_Signatures ; 
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H.4.4  Data  Baaa  Types 

with  Convoy_Builder_Types; 
with  Vehicle_Types; 
with  Measurement_Types ; 
package  DB_Types  is 

Max_Name_Length  :  constant  Positive  : =  20; 

—  Data  construct  to  store  Convoy  Vehicle  and  organization  info, 
packaga  CBT  ran anas  Convoy _Builder_Types ; 

type  Convoy_Element_Type (  Level  :  CBT.Levels_Type  :=  CBT. Vehicle  )  ia 

record 

caaa  Level  ia 

whan  CBT. Level s_Type' Last  => 

Info  :  Vehicle_Types . Vehicle_Combination; 

when  others  =>  null;  --  will  be  Internal_Org  info,  in  future! 

end  case; 

end  record ; 

—  Data  constructs  to  store  other  Convoy  dependent  Parameters 

aubtype  Number_Of_Levels  is  Natural  range  0  . . 

CBT.Levels_Type'Pos(  CBT. Levels_Type' Last  ); 

type  Fixed_Gap_Data  is  array  (  Number_Of_Levels  )  of 

Measurement_Types . Distance_Measurement ; 

type  Govemed_Gap_Data  is  array  {  Number_Of_Levels  )  of 

Measurement_Types . Gap_Multiplier_Type ; 

type  lnt_Orged_Levels  ia  array  (  Number_Of_Levels  range  <>  )  of 

CBT . Levels_Type ; 

type  Convoy_Parameters_Type (  Governed  ;  Boolean  :=  True; 

Org_Levels  :  Number_0f_Levels  := 

Number_Of _Levels ' Last  )  is 

record 

Average_Speed  :  Measurement_Types . Rate_Measurement ; 

Org_Data  ;  Int_Orged_Levels (  1  . .  Org_Levels  ) ; 
ease  Governed  is 
when  True  => 

Go verned_Gap s  :  Governed_Gap_Data ; 
when  False  => 

Fixed_Gaps  :  Fixed_Gap_Data ; 

end  case; 

end  record ; 


end  DB_Types ; 


H.4.5  Data  Base  Imports  (Specification) 


with  Vehicle_Types ; 
with  Map_Types ; 
with  DB_Types; 

pscksgs  Data_Base_Imports  is 

function  Get_Vehicle  rsturn  Vehicle_Types .Vehicle_Type; 
function  Get_Combination  rsturn  Vehicle_Types.Vehicle_Combination; 


function  Map_Name  rsturn  String ; 

function  Get_Vertex  rsturn  Map_Types .Vertex_Type; 
function  Get_Arc  rsturn  Map_Types . Arc_Type ; 
function  Logical_Id_Value  rsturn  Natural ; 

function  Convoy _Name  rsturn  String; 

function  Get_Convoy_Part  rsturn  DB_Types . Convoy_E  lenient  _Type ; 
function  Get_Convoy_Parameters  rsturn  DB_Types . Convoy_Parameters_Type ; 
snd  Data_Base_Imports ; 


H.4.6  Data  Base  Imports  (Body) 

with  Asset_J*anager_Exports; 
with  User_Interf ace_Exports ; 
with  Convoy_Builder_Exports; 
with  Mapper_Exports ; 
packs ga  body  Da ta_Bas e_Imports  is 

pscksgs  AME  rsnanss  Asset_Manager_Exports ; 
packa gs  CBE  rsnsass  Convoy_Builder_Exports; 
packags  MPE  rsnsass  Mapper _Exports ; 
pscksgs  UIE  rsnssss  User_Interface_Exports; 

function  Get_Vehicle  rsturn  Vehicle_Types .Vehicle_Type  is 

bsgin 

rsturn  AME. Vehicle; 
snd  Get_Vehicle; 

function  Get_Combination  rsturn  Vehicle_Types.Vehicle_Combination  is 

bsgin 

rsturn  AME.Vehicle_Combination; 
snd  Get_Conbination; 

f  unction  Map  _Name  rsturn  String  is 
bsgin 

rsturn  UIE.Map_Name; 
snd  MapJJame  ; 
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function  Get_Vertex  return  Map_Types . Vertex_Type  la 

begin 

return  MPE. Vertex ; 
end  Get_Vertex; 

function  Get_Arc  return  Map_Types . Arc_Type  ia 

begin 

return  MPE. Arc; 
end  Get_Arc; 

function  Logical_Id_Value  return  Natural  ie 

begin 

return  UIE.Vertex_Id; 
end  Logical_Id_Value; 

function  Convoy_Name  return  String  ia 
begin 

return  UIE . Convoy_Name ; 
end  Convoy_Name; 

function  Get_Convoy_Part  return  DB_Types.Convoy_Element_Type  ia 

begin 

return  CBE.Convoy_Part; 
end  Get_Convoy_Part; 

function  Get_Convoy_Parameters  return  DB_Types . Convoy_Parameters_Type  ia 

begin 

return  CBE . Parameters ; 
end  Get_Convoy_Parameters; 

end  Data_Base_Imports ; 

H.4.7  Data  Base  Exports 

with  Vehicle_Types; 
with  Map_Types; 
with  Default; 
with  DB_Types ; 

package  Data_Base_Exports  ia 

Records_In_File  :  Natural; 

Model_Id  :  Vehicle_Types .Model_Type; 

Vehicle_Id  :  Vehicle_Types. Specif ic_Vehicle_Id; 

Vehicle  :  Vehicle_Types.Vehicle_Type  :=  Default.General_Vehicle; 
Combination  :  Vehicle_Types.Vehicle_Combination; 

Convoy JName  ;  String  <  1  . .  DB_Types . Max_Name_Length  ) ; 

Convoy_Part  :  DB_Types . Convoy_Element_Type ; 

Convoy_Data  :  DB_Types . Convoy_Parameters_Type ; 

HapJName  :  String  (  1  . .  DB_Types ,  Max_Name_Length  )  ; 

Vertex_Data  :  Map_Types . Ver tex_Type ; 

Arc_Data  :  Map_Types.Arc_Type; 

Logical_Id_Value  :  Natural; 

end  Data_Baae_Exports ; 
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H.4.8  Vehicle  JO  Handler  (Specifiication) 

with  VehicleJTypes  ; 
package  DB_Vehicle_IO  is 

procedure  Open_Mode 1 s_F i 1 e ; 

function  Number.Of .Models  return  Natural; 

procedure  Put_Model (  Vehicle  :  in  VehicleJTypes .Vehicle_Type  ); 
procedure  Get_Model(  Vehicle  :  out  Vehicle_Types . Vehicle_Type  ); 
procedure  Remove.Model (  Vehicle  :  in  Vehicle_Types .Vehicle_Type  ) ; 
procedure  Close.Models.File; 

procedure  Open.Vehicles.File; 

function  Number.Of .Vehicles  return  Natural; 

procedure  Put_Vehicle(  Vehicle  :  in  Vehicle_Types . Vehicle_Type  ); 
procedure  Get_Vehicle(  Vehicle  :  out  Vehicle_Types . Vehicle_Type  ); 
procedure  Remove_Vehicle (  Vehicle  :  in  Vehicle_Types . Vehicle_Type  ); 
procedure  Close.Vehicles.File; 

procedure  Open_Coxnbinations_File; 

function  Number_Of .Combinations  return  Natural; 

procedure  Put_Combination<  Combo  :  in  Vehicle_Types.Vehicle_Combination) ; 

procedure  Get.Combination (Combo  :  out  Vehicle_Types.Vehicle_Combination)  ; 

procedure  Remove.Combination (  Combo  :  in 

VehicleJTypes. Vehicle.Combination  ) ; 

procedure  Close_Combinations_File; 

End_Of_File  :  exception;  —  raised  by  any  Get  that  attempts  a  read  past  EOF 
end  DB_Vehicle_IO; 


MB ***■<*.•. 
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H.4.9  VehicleJO  Handier  (Body) 

with  Direct_Io; 
with  File_Data; 
package  body  DB_Vehicle_IO  la 

package  Veh_IO  la  new  Direct_IO(  vehicle_Types .Vehicle_Type  ); 

package  Combo_IO  la  new  Direct_IO(  Vehicle_Types.Vehicle_Combination  ); 

function  ’  =  ' (  L,  R  :  in  Vehicle_Types .Model_Type  )  return  Boolean 

rename a  Vehicle_Types . *  =  * ; 

function  *  =  ' (  L,  R  :  in  Vehicle_Types. Specif ic_Vehicle_Id  )  return  Boolean 

renames  Vehicle_Types . '=' ; 

function  *=*  (  L,  R  :  in  Vehicle_Types .  Vehicle_Combination  )  return  Boolean 

renames  Vehicle_Types . '=* ; 


Moriel_File  :  Veh_IO.File_Type; 
Vehicle_File  :  Veh_IO.File_Type; 
Combination_File  :  Combo_IO.File_Type; 


procedure  Open_Models_Fi le  ia 

begin 

Veh_IO . Open (  File  =>  Model_File, 

Mode  =>  Veh_Xo.Inout_File, 

Name  =>  File_Data . Path  &  ’Models .LST*  ); 

exception 

when  Veh_IO.Name_Error  => 

Veh_IO. Create (  File  =>  Model_File, 

Mode  =>  Veh_Io.lnout_File, 

Name  =>  File_Data.Path  &  "Models .LST'  ); 

when  others  =>  raise; 

end  Open_Models_File; 

function  Number_Of_Models  return  Natural  ia 

begin 

return  Natural (  Veh_IO.Size(  Model_File  )  ); 

exception 

when  others  =>  return  0; 

end  Number_Of_Models; 

procedure  Put_Model(  Vehicle  :  in  Vehicle_Types. Vehicle_Type  )  is 
DB_Data  :  Vehicle_Types .Vehicle_Type; 

Written  :  Boolean  :=  False; 

begin 

for  Index  in  1. .Veh_IO.Size (  Model_File  )  loop 
Veh_IO . Read (  File  =>  Model_File, 

Item  =>  DB_Data, 

From  =>  Index  ) ; 

if  DB^Data. Properties. Model  =  Vehicle. Properties .Model  then 
Veh^Io. Write {  File  =>  Model_File, 

Item  =>  Vehicle, 

To  =>  Index  ) ; 

Written  True; 
exit; 


and  loop; 

if  not  Written  tben 

Veh_Io .Write (  File  =>  Model_File, 

Item  =>  Vehicle  ) ; 

•nd  if; 

and  Put_Model; 

procedure  Get_Model (  Vehicle  :  out  Vehicle_Types . Vehicle_Type  )  in 

bogin 

Veh_IO.Read(  File  =>  Model_File, 

Item  =>  Vehicle  ) ; 

exception 

when  Veh_Io.End_Error  =>  raise  End_Of_File; 
and  Get_Model ; 

procoduro  Remove_Model (  Vehicle  :  in  Vehicle_Types .Vehicle_Type  )  is 
DB_Data  :  Vehicle_Types . Vehicle_Type; 

Temp_File  ;  Veh_IO . File_Type; 

bogin 

Veh_IO. Create (  File  =>  Temp_File, 

Mode  =>  Veh_IO.Inout_File, 

Name  =>  File_Data . Path  &  ‘Models . TLST'  ); 
for  Index  in  1 . .Veh_IO . Size (  Mode]_File  )  loop 
Veh_IO.Read(  File  =>  Model_File, 

Item  =>  DB_Data, 

From  =>  Index  ) ; 

if  DB_Data. Proper ties. Model  /=  Vehicle. Properties. Model  thon 
Veh_IO .Write (  File  =>  Temp_File, 

Item  =>  DB_Data  ) ; 

ond  if; 
end  loop; 

Veh_Io. Delete (  Model_File  ); 

Veh^IO . Create (  File  =>  Model_File, 

Mode  =>  Veh_IO. Inout_File, 

Name  =>  File_Data. Path  &  ‘Models. LST'  ); 
for  Index  in  1 . ,Veh_IO.Size (  Tenp_File  )  loop 
Veh_IO.Read(  File  =>  Temp_File, 

Item  =>  DB_Data, 

From  =>  Index  ) ; 

Veh_IO. Write (  File  =>  Model_File, 

Item  =>  DB_Data  ) ; 

ond  loop; 

Veh_IO . Delete (  Terap_File  ); 
ond  Remove_Mode 1 ; 

procoduro  Close_Models_File  is 

bogin 

Veh_IO . Close (  Model_File  }; 
ond  C 1 ose_Mode 1 s_F i 1 e ; 


procedure  Open_Vehicles_File  is 

begin 

Veh_I0.0pen(  File  =>  Vehicle_File, 

Mode  =>  Veh_Io.Inout_File, 

Name  =>  File_Data.Path  &  "Vehicles. LST'  ); 

oxcoption 

when  Vah_IO . Name_Error  => 


F 


» 


Veh_IO. Create (  File  =>  Vehicle_File, 

Mode  =>  Veh_Io . Inout_File, 

Name  =>  File_Data.Path  &  'Vehicles. LST'  ); 

whan  others  =>  raise; 

end  Open_Vehicles_File; 

function  Number_Of_Vehicles  return  Natural  is 

begin 

return  Natural (  Veh_IO.Size(  Vehicle_File  )  ); 

exception 

when  others  =>  return  0; 

end  Number_Of_Vehicles; 

procedure  Put_Vehicle(  Vehicle  :  in  Vehicle_Types . Vehicle_Type  )  is 
DB_Data  :  Vehicle_Types . Vehicle_Type ; 

Written  :  Boolean  :=  False; 

begin 

for  Index  in  1 . . Veh_IO . Size {  Vehicle_File  )  loop 
Veh_IO . Read (  File  =>  Vehicle_File , 

Item  =>  DB_Data, 

From  =>  Index  ) ; 

if  DB_Data.Vehicle_ld  =  Vehicle ,Vehicle_Id  then 
Veh_Io .Write {  File  =>  Vehicle_File, 

Item  =>  Vehicle, 

To  =>  Index  ) ; 

Written  :=  True; 
exit; 
end  if; 
end  loop; 

if  not  Written  then 

Veh_Io. Write (  File  =>  Vehicle_File, 

Item  =>  Vehicle  ) , 

end  if; 

end  Put_Vehicle; 

procedure  Get_Vehicle(  Vehicle  :  out  Vehicle_Types .Vehicle_Type  )  is 

begin 

Veh_IO.Read(  File  =>  Vehicle_File, 

Item  =>  Vehicle  > ; 

exception 

whan  Veh_Io . End_Error  =>  raise  End_Of_File; 
and  Get_Vehicle; 

procedure  Remo fe_Vehicle (  Vehicle  :  in  Vehicle_Types.Vehicle_Type  )  is 
DB_Data  :  Vehicle_Types . Vehicle_Type ; 

Temp_File  :  Veh_IO.File_Type; 

begin 

Veh_IO. Create!  File  =>  Temp_File, 

Mode  =>  Veh_IO. Inout_File, 

Name  =>  File_Data . Path  &  'Vehicles .TLST'  ); 
for  Index  in  1. .Veh_IO.Size(  Vehicle_File  )  loop 
Veh_IO.Read{  File  =>  Vehicle_File, 

Item  =>  DB_Data, 

From  =>  Index  ) ; 

if  DB_Data.Vehicle_Id  /=  Vehicle. Vehicle_Id  then 
Veh^IO. Write (  File  =>  Tenqp_File, 

Item  =>  DB_Data  ) ; 

end  if; 
end  loop; 
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Veh_Io. Delete!  Vehicle_File  ); 

Veh_IO . Create (  File  =>  Vehicle_File, 

Mode  =>  Veh_IO. Inout_File, 

Name  =>  File_Data. Path  &  ‘Vehicles .LST*  ); 
for  Index  in  1. .Veh_IO.Size(  Temp_File  )  loop 
Veh_IO.Read(  File  =>  Temp_File, 

Item  =>  DB_Data, 

From  =>  Index  ) ; 

Veh_IO. Write (  File  =>  Vehicle_File, 

Item  =>  DB_Data  ) ; 

end  loop; 

Veh_IO. Delete!  Temp_File  ); 
end  Remove_Vehicle; 


procedure  Close_Vehicles_File  is 

begin 

Veh_IO. Close (  Vehicle_File  ); 
end  Close_Vehicles_File; 


procedure  Open_Combinations_File  is 

begin 

Combo_IO . Open (  File  =>  Combination_File, 

Mode  =>  Combo_Io . Inout_File , 

Name  =>  File_Data. Path  &  "Combinations. LST'  ) ; 

exception 

when  Combo_IO.Name_Error  => 

Combo_IO . Create (  File  =>  Combination_File, 

Mode  =>  Combo_Io.Inout_File, 

Name  =>  File_Data . Path  &  ‘Combinations. LST'  ); 

when  others  =>  raise; 

end  Open_Combinations_File; 

function  Number_0£_Combinations  return  Natural  is 

begin 

return  Natural!  Combo_IO.Size (  Combination_File  )  ); 

exception 

when  others  =>  return  0; 

end  Number_Of_Corobinations; 

procedure  Put_Combination 

(  Combo  ;  in  Vehicle_Types.Vehicle_Combination  )  is 
DB_Data  :  Vehicle_Types. Vehicle_Combination; 

Written  :  Boolean  :=  False; 

begin 

for  Index  in  1. . Combo_IO.Size(  Combination_File  )  loop 
Combo_IO.Read(  File  =>  Combination_File, 

Item  =>  DB_Data, 

From  =>  Index  ) ; 
if  DB_Data  =  Combo  then 

Combo_Io. Write!  File  =>  Combination_File, 


Item  ->  Combo, 
To  =>  Index  ) ; 


Combo_Io . Wr i te ( 

•ad  if; 

•ad  Put_Combination; 


File  =>  Combination_File, 
Item  =>  Combo  ) ; 


procedure  Get_Combi nation 

(  Combo  :  out  Vehicle_Types  Vehicle_Combination  )  is 

begin 

Corobo_IO . Read (  File  =>  Combination_File, 

Item  =>  Combo  ) ; 

exception 

when  Combo_Io . End_Error  =>  rais*  End_Of_File; 

•ad  Get_Combination; 


procedure  Remove_Combination 

(  Combo  :  ia  Vehicle_Types . Vehicle_Combination  )  is 
DB_Data  :  Vehicle_Types . Vehicle^Combination; 

Temp_File  :  Combo_IO . File_Type ; 

begin 

Combo_IO . Create (  File  =>  Temp_File, 

Mode  =>  Combo_IO. Inout_File, 

Name  =>  File_Data.Path  &  ’Combinations. TLST'  ); 
for  Index  in  1. .Combo_IO.Size(  Combination_File  )  loop 
Combo_IO . Read (  File  =>  Combination_File, 

Item  =>  DB_Data, 

From  =>  Index  ) ; 
if  DB_Data  /=  Combo  then 

Combo_IO.Write(  File  =>  Temp_File, 

Item  =>  DB_Data  ) ; 

end  if; 
end  loop; 

Combo_Io. Delete (  Combination_File  ); 

Combo_Io. Create (  File  =>  Combination_File, 

Mode  =>  Combo_IO. Inout_File, 

Name  =>  File_Data.Path  &  ’Combinations .LST*  ); 
for  Index  in  1. .Combo_IO.Size(  Temp_File  )  loop 
Combo_IO . Read (  File  =>  Ten£>_File, 

Item  =>  DB_Data , 

From  =>  Index  ) ; 

Combo_IO. Write (  File  =>  Combination_File, 

Item  =>  DB_Data  ) ; 

end  loop; 

Combo_IO .  Delete  (  Ten*>_File  ); 
end  Remove_Combination; 


procedure  Close_Combinations_File  is 

begin 

Combo_IO. Close (  Combination_File  ); 
end  Close_Combinations_File; 


end  DB_Vehicle_IO; 
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